Google Search MCP Server
Provides advanced Google Custom Search functionality including web search, content extraction, search analytics, multi-site search, news monitoring, academic research, content summarization, fact checking, research assistance, and search trends.
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 for recent breakthroughs in renewable energy"
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
A comprehensive Model Context Protocol (MCP) server that provides advanced Google Custom Search functionality, web content extraction, search analytics, and specialized research tools. This server transforms Google's search capabilities into powerful AI tools that can be integrated with any MCP-compatible AI client.
Table of Contents
Features
Advanced Google Search: Perform web searches with extensive filtering options, file type restrictions, and geographic targeting
Content Extraction: Extract main content from web pages with automatic sentiment analysis
Search Analytics: Analyze search trends across multiple queries with comprehensive insights and keyword extraction
Multi-Site Search: Search across multiple websites simultaneously with detailed statistics
News Monitoring: Monitor news sources with topic filtering and date restrictions
Academic Research: Specialized tools for finding academic papers and research documents
Content Summarization: Intelligent summarization of multiple URLs with sentiment analysis and insights
Fact Checking: Automated fact verification with evidence-based results
Search Trends: Real-time search interest analysis and trend prediction
Cached Resources: 8 specialized resources providing cached search results, analytics, and research data
MCP Compatible: Seamlessly integrates with any MCP-compatible AI client (Claude, Cursor, etc.)
Robust Error Handling: Comprehensive error handling for API failures, rate limiting, and invalid parameters
Intelligent Caching: TTL-based caching system optimizing performance and API usage
TypeScript: Fully typed with Zod schema validation for all parameters
Prerequisites
Node.js 18+
Google Custom Search API key
Google Custom Search Engine ID
Installation
Clone this repository:
git clone https://github.com/1999AZZAR/mcp-server-google-search.git
cd mcp-server-google-searchInstall dependencies:
npm installBuild the project:
npm run buildVerify installation:
# Test that the server starts correctly
echo '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}' | GOOGLE_API_KEY=test GOOGLE_CSE_ID=test node dist/index.jsConfiguration
Environment Variables
Create a .env file in the project root with the following variables:
GOOGLE_API_KEY=your_google_api_key_here
GOOGLE_CSE_ID=your_custom_search_engine_id_hereGetting Google API Credentials
Step 1: Google Cloud Console Setup
Go to the Google Cloud Console
Create a new project or select an existing one
Enable the "Custom Search API" in the API Library
Go to "Credentials" → "Create Credentials" → "API Key"
Copy your API key
Step 2: Custom Search Engine Setup
Click "Add" to create a new search engine
Enter the sites you want to search (or leave blank for entire web)
Give your search engine a name
Click "Create"
Go to "Setup" → "Basics" and copy your "Search engine ID"
Step 3: Configure Search Engine (Optional)
Search the entire web: Leave "Sites to search" empty
Search specific sites: Add domains like
github.com,stackoverflow.comAdvanced settings: Configure language, region, and other preferences
Security Best Practices
Never commit your
.envfile to version controlUse environment variables in production
Consider using Google Cloud Secret Manager for production deployments
Restrict your API key to specific IP addresses if possible
Usage
As an MCP Server
For Cursor IDE
Add this server to your Cursor MCP configuration (~/.cursor/mcp.json):
{
"mcpServers": {
"google-search-mcp": {
"command": "node",
"args": ["/path/to/mcp-server-google-search/dist/index.js"],
"env": {
"GOOGLE_API_KEY": "your_api_key",
"GOOGLE_CSE_ID": "your_cse_id"
}
}
}
}For Claude Desktop
Add this server to your Claude Desktop configuration (claude_desktop_config.json):
{
"mcpServers": {
"google-search-mcp": {
"command": "node",
"args": ["/path/to/mcp-server-google-search/dist/index.js"],
"env": {
"GOOGLE_API_KEY": "your_api_key",
"GOOGLE_CSE_ID": "your_cse_id"
}
}
}
}For Other MCP Clients
The server follows the standard MCP protocol and should work with any MCP-compatible client. Refer to your client's documentation for configuration details.
Testing the Server
You can test the server directly using JSON-RPC commands:
# List all available tools
echo '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}' | GOOGLE_API_KEY=your_key GOOGLE_CSE_ID=your_id node dist/index.js
# Test a search
echo '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"google_search","arguments":{"q":"test search","num":2}}}' | GOOGLE_API_KEY=your_key GOOGLE_CSE_ID=your_id node dist/index.jsAvailable Tools
This MCP server provides 10 powerful tools for comprehensive search, research, fact verification, trend analysis, and advanced research assistance:
1. Google Search (google_search)
Perform advanced web searches with extensive filtering options and geographic targeting.
Parameters:
q(required): Search query stringfileType(optional): File type filter - "pdf", "doc", "docx", "ppt", "pptx", "xls", "xlsx", "rtf"siteSearch(optional): Search within a specific site (e.g., "example.com")dateRestrict(optional): Date restriction - "d1", "w1", "m1", "y1", "d7", "w2", "m2", "y2", "m6", "y"safe(optional): Safe search level - "active", "off"exactTerms(optional): Terms that must appear exactly as specifiedexcludeTerms(optional): Terms to exclude from search resultssort(optional): Sort order - "date"gl(optional): Country code for geolocation (e.g., "us", "uk")hl(optional): Language code for interface (e.g., "en", "es")num(optional): Number of results to return (1-10)start(optional): Starting index for results (1-based)
Use Cases:
General web searches with advanced filtering
Finding specific file types (PDFs, documents)
Searching within specific websites
Time-restricted searches for recent content
Example:
{
"name": "google_search",
"arguments": {
"q": "artificial intelligence",
"num": 5,
"fileType": "pdf",
"dateRestrict": "m1"
}
}Response Format:
{
"searchInfo": {
"totalResults": "8420000",
"searchTime": 0.626612,
"formattedSearchTime": "0.63"
},
"items": [
{
"title": "Article Title",
"link": "https://example.com/article",
"snippet": "Article preview...",
"displayLink": "example.com",
"formattedUrl": "https://example.com/article"
}
]
}2. Extract Content (extract_content)
Extract main content from web pages and perform automatic sentiment analysis using advanced text processing.
Parameters:
url(required): URL of the web page to extract content from
Use Cases:
Summarizing articles and blog posts
Analyzing sentiment of news articles or reviews
Extracting clean text from web pages
Content analysis for research purposes
Example:
{
"name": "extract_content",
"arguments": {
"url": "https://example.com/article"
}
}Response Format:
{
"url": "https://example.com/article",
"title": "Article Title",
"content": "Extracted main content...",
"wordCount": 1250,
"sentiment": {
"score": 0.8,
"comparative": 0.15,
"positive": 0.75,
"negative": 0.25,
"neutral": 0.0
},
"summary": "Brief summary of the content..."
}3. Search Analytics (search_analytics)
Analyze search trends across multiple queries with comprehensive insights, keyword extraction, and performance metrics.
Parameters:
queries(required): Array of search queries to analyze (1-5 queries)timeRange(optional): Time range for trend analysis - "week", "month", "year"maxResults(optional): Maximum results per query (1-5)
Use Cases:
Market research and trend analysis
Keyword research for SEO
Competitive analysis
Content strategy planning
Brand monitoring
Example:
{
"name": "search_analytics",
"arguments": {
"queries": ["artificial intelligence", "machine learning", "deep learning"],
"timeRange": "month",
"maxResults": 3
}
}Response Format:
{
"queries": ["artificial intelligence", "machine learning", "deep learning"],
"timeRange": "month",
"results": [
{
"query": "artificial intelligence",
"resultCount": 1600000000,
"items": [...]
}
],
"summary": {
"totalResults": 7060000000,
"averageResults": 2353333333.33,
"topPerformingQuery": "deep learning",
"commonKeywords": ["learning", "artificial", "intelligence", "machine", "deep"]
}
}4. Multi-Site Search (multi_site_search)
Search across multiple specific websites simultaneously with detailed statistics and comprehensive results aggregation.
Parameters:
query(required): Search querysites(required): Array of websites to search (1-5 sites)maxResults(optional): Max results per site (1-5)fileType(optional): File type to search for
Use Cases:
Cross-platform research (GitHub, Stack Overflow, Medium)
Competitive analysis across multiple sites
Finding resources on specific platforms
Aggregating information from trusted sources
Example:
{
"name": "multi_site_search",
"arguments": {
"query": "react tutorial",
"sites": ["github.com", "stackoverflow.com", "dev.to"],
"maxResults": 3
}
}Response Format:
{
"query": "react tutorial",
"sites": ["github.com", "stackoverflow.com", "dev.to"],
"results": [
{
"site": "github.com",
"resultCount": 2,
"totalAvailable": 19800,
"items": [...]
}
],
"summary": {
"totalResults": 6,
"sitesSearched": 3,
"successfulSearches": 3
}
}5. News Monitor (news_monitor)
Monitor news sources for specific topics with advanced filtering, source targeting, and date restrictions for real-time news intelligence.
Parameters:
topic(required): Topic to monitorsources(optional): Array of news sources to monitor (e.g., ["bbc.com", "cnn.com", "reuters.com"])language(optional): Language code (e.g., "en", "es")country(optional): Country code (e.g., "us", "uk")maxResults(optional): Maximum results to return (1-10)dateRestrict(optional): Date restriction for news - "d1", "d7", "m1", "m6", "y1"
Use Cases:
Real-time news monitoring
Brand and reputation management
Crisis communication monitoring
Industry trend tracking
Competitive intelligence
Example:
{
"name": "news_monitor",
"arguments": {
"topic": "artificial intelligence breakthrough",
"sources": ["bbc.com", "cnn.com", "reuters.com"],
"dateRestrict": "d7",
"maxResults": 5
}
}Response Format:
{
"topic": "artificial intelligence breakthrough",
"sources": ["bbc.com", "cnn.com", "reuters.com"],
"language": "en",
"country": "us",
"dateRestrict": "d7",
"results": [
{
"source": "bbc.com",
"articles": [...]
}
],
"summary": {
"totalArticles": 15,
"sourcesFound": 3,
"dateRange": "d7"
}
}6. Academic Search (academic_search)
Search academic papers and research documents from specialized academic sources with PDF filtering and publication date restrictions.
Parameters:
query(required): Research queryfileType(optional): File type (PDF only) - "pdf"dateRange(optional): Publication date range - "d1", "d7", "m1", "m6", "y1", "y2"sites(optional): Academic sites to search (default: ["arxiv.org", "scholar.google.com", "researchgate.net"])maxResults(optional): Maximum results to return (1-10)
Use Cases:
Academic research and literature reviews
Finding recent research papers
PhD and thesis research
Scientific literature analysis
Research trend monitoring
Example:
{
"name": "academic_search",
"arguments": {
"query": "machine learning algorithms neural networks",
"fileType": "pdf",
"dateRange": "y1",
"sites": ["arxiv.org", "scholar.google.com"],
"maxResults": 5
}
}Response Format:
{
"query": "machine learning algorithms neural networks",
"fileType": "pdf",
"dateRange": "y1",
"sites": ["arxiv.org", "scholar.google.com"],
"results": [
{
"site": "arxiv.org",
"paperCount": 3,
"totalAvailable": 18800,
"papers": [
{
"title": "A Digital Machine Learning Algorithm Simulating Spiking Neural Networks",
"link": "https://arxiv.org/pdf/2503.17111",
"snippet": "During last several years, our research team worked on development of a spiking neural network...",
"mime": "application/pdf",
"fileFormat": "PDF/Adobe Acrobat"
}
]
}
],
"summary": {
"totalPapers": 3,
"sitesSearched": 2,
"successfulSearches": 2,
"dateRange": "y1"
}
}7. Content Summarizer (content_summarizer)
Extract and summarize content from multiple URLs with intelligent summarization, sentiment analysis, and comprehensive insights.
Parameters:
urls(required): Array of URLs to summarize (1-10 URLs)maxLength(optional): Maximum length of summary per URL in words (50-500, default: 200)includeSentiment(optional): Include sentiment analysis for each URL (default: true)focusAreas(optional): Specific areas to focus on in summaries (e.g., ["key points", "conclusions", "data"])generateOverallSummary(optional): Generate an overall summary combining all URLs (default: true)
Use Cases:
Research summarization across multiple sources
Content analysis and comparison
News aggregation and analysis
Academic paper summarization
Competitive intelligence gathering
Content curation and insights
Example:
{
"name": "content_summarizer",
"arguments": {
"urls": [
"https://example.com/article1",
"https://example.com/article2",
"https://example.com/article3"
],
"maxLength": 150,
"includeSentiment": true,
"focusAreas": ["key insights", "conclusions", "data"],
"generateOverallSummary": true
}
}Response Format:
{
"urls": ["https://example.com/article1", "https://example.com/article2"],
"maxLength": 150,
"includeSentiment": true,
"focusAreas": ["key insights", "conclusions"],
"generateOverallSummary": true,
"summaries": [
{
"url": "https://example.com/article1",
"title": "Article Title",
"summary": "Key insights from the article...",
"wordCount": 1250,
"sentiment": {
"score": 0.8,
"comparative": 0.15,
"positive": ["excellent", "innovative"],
"negative": ["challenging"]
},
"extractionTime": "2024-01-15T10:30:00.000Z"
}
],
"overallSummary": "Combined insights from all articles...",
"statistics": {
"totalUrls": 2,
"successfulExtractions": 2,
"failedExtractions": 0,
"averageWordCount": 1250,
"sentimentDistribution": {
"positive": 1,
"negative": 0,
"neutral": 1
}
}
}8. Fact Checker (fact_checker)
Verify claims by searching multiple authoritative sources with credibility analysis and evidence extraction.
Parameters:
claim(required): The claim or statement to verify (minimum 10 characters)sources(optional): Specific authoritative sources to check (e.g., ["wikipedia.org", "bbc.com", "reuters.com"])confidenceThreshold(optional): Minimum confidence level for verification (0.0-1.0, default: 0.7)timeframe(optional): Time range for search results - "d1", "d7", "m1", "m6", "y1", "y2" (default: "y1")maxResults(optional): Maximum results per source (1-5, default: 3)includeEvidence(optional): Include extracted evidence snippets (default: true)
Default Sources:
wikipedia.org, bbc.com, reuters.com, ap.org
factcheck.org, snopes.com, politifact.com
scholar.google.com, pubmed.ncbi.nlm.nih.gov, nature.com
Use Cases:
Fact verification and debunking misinformation
Research validation across multiple sources
News verification and credibility assessment
Academic claim verification
Public statement fact-checking
Scientific claim validation
Example:
{
"name": "fact_checker",
"arguments": {
"claim": "The Earth is approximately 4.5 billion years old",
"sources": ["wikipedia.org", "science.org", "nature.com"],
"confidenceThreshold": 0.8,
"timeframe": "y1",
"maxResults": 2,
"includeEvidence": true
}
}Response Format:
{
"claim": "The Earth is approximately 4.5 billion years old",
"sourcesToCheck": ["wikipedia.org", "science.org", "nature.com"],
"confidenceThreshold": 0.8,
"timeframe": "y1",
"maxResults": 2,
"includeEvidence": true,
"verification": {
"status": "verified",
"confidence": 0.85,
"evidenceCount": 4,
"supportingSources": ["wikipedia.org", "science.org"],
"disputingSources": [],
"neutralSources": ["nature.com"]
},
"sources": [
{
"source": "wikipedia.org",
"resultCount": 2,
"totalAvailable": "3700",
"results": [
{
"title": "Age of Earth - Wikipedia",
"link": "https://en.wikipedia.org/wiki/Age_of_Earth",
"snippet": "The age of Earth is estimated to be 4.54 ± 0.05 billion years...",
"displayLink": "en.wikipedia.org",
"relevanceScore": 0.8
}
],
"credibilityScore": 0.8
}
],
"evidence": [
{
"source": "wikipedia.org",
"url": "https://en.wikipedia.org/wiki/Age_of_Earth",
"title": "Age of Earth - Wikipedia",
"evidence": "The age of Earth is estimated to be 4.54 ± 0.05 billion years. This age represents the final stages of Earth's accretion and planetary differentiation.",
"relevanceScore": 0.8,
"sentiment": {
"score": 0,
"comparative": 0
}
}
],
"statistics": {
"totalSourcesChecked": 3,
"successfulSearches": 3,
"failedSearches": 0,
"totalResults": 6,
"averageRelevanceScore": 0.75
}
}Verification Statuses:
verified: Claim is supported by credible sources with high confidencedisputed: Claim is contradicted by credible sourcesunverified: Insufficient evidence or conflicting informationunknown: No relevant information found
9. Research Assistant (research_assistant)
10. Search Trends (search_trends)
Track and analyze search interest trends over time with predictive insights and emerging topic discovery. This tool provides comprehensive trend analysis by combining current search data with historical patterns to identify emerging topics and predict future interest levels.
Parameters:
topics(required): Array of topics to track trends for (1-5 topics)timeframe(optional): Time period to analyze ('1M', '3M', '6M', '1Y', '2Y') - defaults to '6M'region(optional): Geographic region for trend analysis (country code like 'US', 'GB', 'CA') - defaults to 'US'category(optional): Category filter for more targeted trend analysis ('all', 'business', 'entertainment', 'health', 'politics', 'science', 'sports', 'technology') - defaults to 'all'includePredictions(optional): Include trend prediction and forecasting - defaults to truerelatedTopics(optional): Discover and include related trending topics - defaults to true
Use Cases:
Market research and trend analysis
Content strategy and topic planning
Competitive analysis and market intelligence
Emerging technology tracking
Brand monitoring and reputation management
Seasonal trend analysis
Predictive content planning
Example:
{
"name": "search_trends",
"arguments": {
"topics": ["artificial intelligence", "machine learning"],
"timeframe": "6M",
"region": "US",
"category": "technology",
"includePredictions": true,
"relatedTopics": true
}
}Response Format:
{
"topics": ["artificial intelligence", "machine learning"],
"timeframe": "6M",
"region": "US",
"category": "technology",
"includePredictions": true,
"relatedTopics": true,
"trends": [
{
"topic": "artificial intelligence",
"currentInterest": 245000000,
"recentActivity": 3,
"trendDirection": "increasing",
"changePercent": 12.45,
"peakPeriod": "Month 5",
"data": [65, 68, 72, 75, 78, 80, 82, 85, 87, 89, 91, 93, 94, 95, 96, 97, 98, 98, 99, 99, 100, 99, 98, 97]
}
],
"relatedTopics": [
{
"topic": "artificial intelligence",
"relatedTopics": ["neural", "networks", "deep", "learning", "automation"]
}
],
"predictions": [
{
"topic": "artificial intelligence",
"prediction": "artificial intelligence shows increasing interest. Expected to continue growing by 18.45% in the next period.",
"confidence": 0.75,
"timeframe": "next period",
"factors": [
"Current market trends",
"Seasonal patterns",
"Related topic performance",
"Search volume patterns"
]
}
],
"timestamp": "2025-11-02T17:04:02.839Z"
}9. Research Assistant (research_assistant)
Comprehensive research assistant with multi-step workflows, source synthesis, and structured report generation.
Parameters:
researchTopic(required): The main research topic or question to investigate (minimum 10 characters)researchType(optional): Type of research to conduct - "academic", "news", "factual", "comprehensive" (default: "comprehensive")depth(optional): Research depth level - "quick", "standard", "deep" (default: "standard")sources(optional): Specific sources to include in research (max 15 sources)excludeSources(optional): Sources to exclude from research (max 10 sources)timeframe(optional): Time range for research results - "d1", "d7", "m1", "m6", "y1", "y2" (default: "y1")maxSourcesPerType(optional): Maximum sources per source type (2-8, default: 5)includeCitations(optional): Include detailed citations and source tracking (default: true)generateReport(optional): Generate structured research report (default: true)focusAreas(optional): Specific areas to focus research on (e.g., ["methodology", "findings", "implications"])
Research Types & Source Categories:
Academic: Academic journals, educational institutions, research repositories
News: News sources, fact checkers, international media
Factual: Government sources, scientific institutions, reference materials
Comprehensive: All source types for thorough research
Use Cases:
Academic research and literature reviews
Market research and competitive analysis
Policy research and government analysis
Scientific research and evidence synthesis
Business intelligence and strategic planning
News analysis and media monitoring
Fact-checking and verification workflows
Example:
{
"name": "research_assistant",
"arguments": {
"researchTopic": "artificial intelligence impact on healthcare",
"researchType": "comprehensive",
"depth": "standard",
"maxSourcesPerType": 3,
"focusAreas": ["methodology", "findings", "implications"],
"includeCitations": true,
"generateReport": true,
"timeframe": "y1"
}
}Response Format:
{
"researchTopic": "artificial intelligence impact on healthcare",
"researchType": "comprehensive",
"depth": "standard",
"timeframe": "y1",
"maxSourcesPerType": 3,
"includeCitations": true,
"generateReport": true,
"focusAreas": ["methodology", "findings", "implications"],
"researchWorkflow": {
"phase": "completed",
"stepsCompleted": 5,
"totalSteps": 5,
"currentStep": "Research completed"
},
"sourceCategories": ["Academic", "News", "Government", "Reference", "Specialized"],
"findings": [
{
"source": "nature.com",
"category": "Academic",
"url": "https://example.com/article",
"title": "AI in Healthcare Research",
"content": "Full extracted content...",
"wordCount": 1250,
"sentiment": {
"score": 0.8,
"comparative": 0.15
},
"relevanceScore": 0.9,
"keyInsights": ["AI shows promise in diagnostic accuracy", "Implementation challenges remain"],
"focusAnalysis": {
"methodology": ["Randomized controlled trials", "Machine learning algorithms"],
"findings": ["Improved diagnostic accuracy by 15%", "Reduced false positives"],
"implications": ["Potential for widespread adoption", "Need for regulatory framework"]
},
"contentQualityScore": 0.85,
"extractionTime": "2024-01-15T10:30:00.000Z"
}
],
"sources": [
{
"source": "nature.com",
"category": "Academic",
"resultCount": 3,
"totalAvailable": "150",
"results": [
{
"title": "AI in Healthcare Research",
"link": "https://example.com/article",
"snippet": "Artificial intelligence is transforming healthcare...",
"displayLink": "nature.com",
"relevanceScore": 0.9
}
],
"credibilityScore": 0.9
}
],
"citations": [
{
"title": "AI in Healthcare Research",
"url": "https://example.com/article",
"source": "nature.com",
"category": "Academic",
"credibilityScore": 0.9,
"relevanceScore": 0.9,
"accessedDate": "2024-01-15T10:30:00.000Z"
}
],
"synthesis": {
"keyFindings": [
"AI demonstrates significant potential in healthcare diagnostics",
"Implementation faces regulatory and technical challenges",
"Patient outcomes show measurable improvement with AI assistance"
],
"conflictingInformation": [],
"consensusPoints": [
"AI technology shows promise in healthcare applications",
"Regulatory frameworks need development for safe implementation"
],
"gapsInKnowledge": [
"Long-term impact studies are limited",
"Cost-benefit analysis needs more research"
],
"confidenceLevel": 0.85
},
"report": {
"title": "Research Report: artificial intelligence impact on healthcare",
"executiveSummary": "This research analyzed 15 sources across 5 categories...",
"methodology": "Research methodology involved systematic search...",
"findings": "Key findings from the research:\n1. AI shows promise...",
"synthesis": "Synthesis of findings reveals 2 consensus points...",
"recommendations": "High confidence in findings. Recommendations can be made...",
"limitations": "Research limitations include: limited to publicly available sources...",
"citations": [...],
"metadata": {
"generatedAt": "2024-01-15T10:30:00.000Z",
"researchType": "comprehensive",
"depth": "standard",
"totalSources": 15,
"confidenceLevel": 0.85,
"qualityScore": 0.82
}
},
"statistics": {
"totalSourcesSearched": 15,
"successfulSearches": 14,
"failedSearches": 1,
"totalResults": 45,
"averageCredibilityScore": 0.87,
"researchQualityScore": 0.82
}
}Research Workflow Phases:
Multi-source Research: Systematic search across categorized sources
Content Analysis: Extraction, sentiment analysis, and focus area analysis
Synthesis: Cross-reference analysis and consensus identification
Citation Management: Automated citation generation and tracking
Report Generation: Structured research report with executive summary
Quality Metrics:
Research Quality Score: Composite score based on source diversity, credibility, and findings quality
Confidence Level: Overall confidence in research findings based on source agreement
Source Diversity: Number of different source categories included
Content Quality: Assessment of extracted content relevance and depth
Available Resources
Google Search MCP Server provides 8 specialized resources that offer cached search results, trend analysis, and research data with intelligent caching for optimal performance:
google://search/cache/{query}
Returns cached Google search results for a query with metadata and timestamps.
Resource Details:
Purpose: Access recently cached search results without API calls
Benefits: Faster response times, reduced API usage, offline capability for recent searches
Cache TTL: 5 minutes - balances freshness with performance
Use Cases: Frequently accessed search terms, monitoring queries, development testing
Response Format:
{
"query": "artificial intelligence",
"results": [
{
"title": "Artificial Intelligence - Wikipedia",
"link": "https://en.wikipedia.org/wiki/Artificial_intelligence",
"snippet": "Artificial intelligence (AI) is intelligence demonstrated by machines..."
}
],
"searchTime": "0.25",
"totalResults": "about 2,450,000,000",
"cached": false,
"timestamp": "2025-11-02T17:09:14.866Z"
}google://search/trends/{topic}
Provides search interest trends and predictions for topics over time.
Resource Details:
Purpose: Analyze search interest patterns and predict trends
Benefits: Market research, content strategy, trend identification
Cache TTL: 5 minutes - keeps trend data reasonably current
Use Cases: SEO analysis, content planning, market research
Response Format:
{
"topic": "machine learning",
"trends": {
"interest": [25, 30, 45, 60, 55, 70],
"timeframe": "6M",
"region": "US",
"predictions": [75, 80, 85]
},
"cached": false,
"timestamp": "2025-11-02T17:09:14.866Z"
}google://search/analytics/{query}
Provides comprehensive search analytics including multiple results and patterns.
Resource Details:
Purpose: Deep analysis of search results and patterns
Benefits: Comprehensive search intelligence and pattern recognition
Cache TTL: 5 minutes - ensures analytical data stays relevant
Use Cases: Competitive analysis, keyword research, content optimization
Response Format:
{
"query": "renewable energy",
"analytics": {
"totalResults": 1250000,
"topDomains": ["wikipedia.org", "energy.gov", "iea.org"],
"contentTypes": ["educational": 45, "commercial": 30, "news": 25],
"sentiment": {"positive": 0.6, "neutral": 0.3, "negative": 0.1}
},
"cached": false,
"timestamp": "2025-11-02T17:09:14.866Z"
}google://content/extracted/{url}
Provides cached extracted content with sentiment analysis from web pages.
Resource Details:
Purpose: Access processed web content without re-extraction
Benefits: Faster content analysis, reduced processing overhead
Cache TTL: 5 minutes - balances content freshness with performance
Use Cases: Content monitoring, sentiment analysis, data extraction
Response Format:
{
"url": "https://example.com/article",
"content": {
"title": "Article Title",
"text": "Full article content...",
"wordCount": 1250,
"sentiment": {
"score": 0.3,
"comparative": 0.024,
"tokens": ["article", "content", "analysis"],
"words": ["good", "excellent"],
"positive": ["good", "excellent"],
"negative": []
},
"readability": 72.5
},
"cached": false,
"timestamp": "2025-11-02T17:09:14.866Z"
}google://news/recent/{topic}
Provides recent news articles with credibility analysis for topics.
Resource Details:
Purpose: Access recent news with quality filtering
Benefits: Time-sensitive information with credibility scoring
Cache TTL: 2 minutes - ensures news stays current
Use Cases: News monitoring, crisis management, current events tracking
Response Format:
{
"topic": "climate change",
"news": {
"articles": [
{
"title": "New Climate Report Released",
"source": "reuters.com",
"credibility": 0.95,
"published": "2025-11-02T15:30:00Z",
"summary": "Latest IPCC report details..."
}
],
"totalArticles": 15,
"avgCredibility": 0.87
},
"cached": false,
"timestamp": "2025-11-02T17:09:14.866Z"
}google://academic/results/{query}
Provides cached academic papers and research documents.
Resource Details:
Purpose: Access scholarly research without repeated searches
Benefits: Faster academic research, reduced API usage for research queries
Cache TTL: 30 minutes - academic content changes less frequently
Use Cases: Literature reviews, research planning, academic writing
Response Format:
{
"query": "quantum computing",
"results": {
"papers": [
{
"title": "Advances in Quantum Computing",
"authors": ["Dr. Jane Smith", "Dr. John Doe"],
"journal": "Nature Physics",
"year": 2025,
"citations": 45,
"doi": "10.1038/s41567-025-01234-5"
}
],
"totalPapers": 1250,
"disciplines": ["Physics", "Computer Science", "Mathematics"]
},
"cached": false,
"timestamp": "2025-11-02T17:09:14.866Z"
}google://research/summary/{topic}
Provides comprehensive research summaries with sources and analysis.
Resource Details:
Purpose: Access complete research synthesis without reprocessing
Benefits: In-depth research insights with comprehensive analysis
Cache TTL: 1 hour - research summaries are stable over longer periods
Use Cases: Executive summaries, research reports, strategic planning
Response Format:
{
"topic": "blockchain technology",
"summary": {
"executiveSummary": "Blockchain technology continues to evolve...",
"keyFindings": [
"Decentralized consensus mechanisms improving",
"Enterprise adoption accelerating",
"Regulatory frameworks emerging"
],
"sourcesAnalyzed": 25,
"confidenceLevel": 0.89,
"methodology": "Multi-source analysis with peer review"
},
"cached": false,
"timestamp": "2025-11-02T17:09:14.866Z"
}google://fact/check/{claim}
Provides fact verification results with supporting evidence.
Resource Details:
Purpose: Access fact-checking results for claims
Benefits: Reliable fact verification with evidence trails
Cache TTL: 24 hours - facts don't change frequently
Use Cases: Content verification, journalism, educational fact-checking
Response Format:
{
"claim": "The Earth is flat",
"verification": {
"verdict": "False",
"confidence": 1.0,
"evidence": [
{
"source": "NASA Scientific Consensus",
"type": "Scientific Evidence",
"strength": "Overwhelming",
"summary": "Multiple independent measurements confirm spherical Earth"
}
],
"lastUpdated": "2025-11-01T10:00:00Z"
},
"cached": false,
"timestamp": "2025-11-02T17:09:14.866Z"
}Development
Development Commands
# Install dependencies
npm install
# Run in development mode with hot reload
npm run dev
# Build the project
npm run build
# Run tests
npm test
# Run linting
npm run lint
# Start production server
npm startProject Structure
mcp-server-google-search/
├── dist/ # Compiled JavaScript output
├── __tests__/ # Test files
│ └── mcp-server.test.ts # MCP server tests
├── config.ts # Configuration and environment variables
├── index.ts # Main entry point
├── mcp-server.ts # MCP server implementation with all 6 tools
├── package.json # Dependencies and scripts
├── tsconfig.json # TypeScript configuration
├── jest.config.js # Jest testing configuration
├── global.d.ts # TypeScript declarations
├── .env.example # Environment variables template
├── example-config.json # MCP configuration example
├── README.md # This comprehensive documentation
└── LICENSE # MIT LicenseTechnical Details
Language: TypeScript with ES modules
Runtime: Node.js 18+
Protocol: Model Context Protocol (MCP)
Validation: Zod schemas for all parameters
HTTP Client: Axios for API requests
HTML Parsing: Cheerio for content extraction
Sentiment Analysis: Sentiment library
Testing: Jest with TypeScript support
Error Handling
The server includes comprehensive error handling for:
API Authentication: Invalid Google API credentials
Network Issues: Timeouts, connection failures, rate limiting
Parameter Validation: Invalid search parameters and malformed requests
Content Extraction: Failed web page parsing and extraction
Rate Limiting: Google API quota exceeded
Malformed URLs: Invalid URLs for content extraction
Performance Features
Concurrent Requests: Parallel processing for multi-site searches
Error Recovery: Graceful degradation when individual sources fail
Response Caching: Efficient result aggregation and statistics
Memory Management: Optimized for long-running MCP server processes
License
This project is licensed under the MIT License - see the LICENSE file for details.
Contributing
We welcome contributions! Here's how you can help:
Fork the repository on GitHub
Create a feature branch:
git checkout -b feature/amazing-featureMake your changes and add tests if applicable
Run the test suite:
npm testCommit your changes:
git commit -m 'Add amazing feature'Push to the branch:
git push origin feature/amazing-featureOpen a Pull Request on GitHub
Areas for Contribution
New Tools: Add specialized search tools for specific domains
Enhanced Analytics: Improve search analytics and trend analysis
Performance: Optimize API calls and response times
Documentation: Improve examples and use cases
Testing: Add more comprehensive test coverage
Error Handling: Enhance error messages and recovery
Support
Getting Help
GitHub Issues: Open an issue for bugs or feature requests
Discussions: Use GitHub Discussions for questions and community support
Documentation: Check this README for comprehensive usage examples
Common Issues
API Key Issues: Ensure your Google API key is valid and has Custom Search API enabled
CSE ID Problems: Verify your Custom Search Engine ID is correct
Rate Limiting: Google API has daily quotas - check your usage in Google Cloud Console
MCP Client Issues: Restart your MCP client after configuration changes
Useful Links
About
This MCP server transforms Google's powerful search capabilities into intelligent AI tools, enabling seamless integration with modern AI assistants. Built with TypeScript and following MCP standards, it provides a robust foundation for search-powered AI applications.
Repository: https://github.com/1999AZZAR/mcp-server-google-search
Created by: 1999AZZAR
License: MIT
Made with dedication for the AI community
Available Tools
10 toolsacademic_searchC
Search academic papers and research documents
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Research query | |
| fileType | No | File type (PDF only) | |
| dateRange | No | Publication date range | y1 |
| sites | No | Academic sites to search | |
| maxResults | No | Maximum results to return |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure, but it only restates the purpose. It omits important details: whether it searches only the default sites, output format, authentication needs, or rate limits.
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 overly brief—a single sentence that does not justify its length for a tool with five parameters and no annotations. It sacrifices necessary detail for conciseness, resulting in under-specification.
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 complexity (5 params, 2 enums, no output schema, no annotations), the description provides virtually no context about behavior, return values, or limitations. It is completely inadequate for informed selection and invocation.
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 input schema fully describes all parameters with 100% coverage, so the description adds no additional meaning. Baseline of 3 is appropriate as the schema does the heavy lifting.
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 searches academic papers and research documents, with a specific verb and resource. However, it does not explicitly differentiate from sibling tools like google_search or research_assistant, but the academic focus is evident.
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 is provided on when to use this tool versus alternatives. The description lacks context on appropriate scenarios or exclusions, making it difficult for an agent to distinguish usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
content_summarizerB
Extract and summarize content from multiple URLs with sentiment analysis and intelligent insights
| Name | Required | Description | Default |
|---|---|---|---|
| urls | Yes | Array of URLs to summarize (1-10 URLs) | |
| maxLength | No | Maximum length of summary per URL in words | |
| includeSentiment | No | Include sentiment analysis for each URL | |
| focusAreas | No | Specific areas to focus on in summaries (e.g., ["key points", "conclusions", "data"]) | |
| generateOverallSummary | No | Generate an overall summary combining all URLs |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description should disclose behavioral traits like error handling, rate limits, or idempotency. It only describes the output vaguely, missing important context for a multi-URL processing 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 a single efficient sentence, front-loading the core action. It could be slightly more structured to separate features.
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?
No output schema exists, so the description must explain return values. It does not mention the format or content of summaries, sentiment scores, or combined results, leaving a significant gap.
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 description adds minimal value beyond the schema. The mention of 'sentiment analysis and intelligent insights' hints at parameters but is not essential.
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 extracts and summarizes content from multiple URLs, with sentiment analysis and insights. This distinguishes it from siblings like extract_content or fact_checker.
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 like extract_content or multi_site_search. The description does not mention appropriate scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
extract_contentC
Extract main content and analyze sentiment from a web page
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL of the web page to extract content from |
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 states the tool extracts and analyzes, but does not detail potential issues like JavaScript execution, rate limits, or failure modes. The read-only nature is implied but not explicit.
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 of 10 words, concise and to the point. However, it could benefit from a slightly more structured format (e.g., listing the two actions separately).
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 lack of output schema and annotations, the description should provide more details about the return value (e.g., format of extracted content, sentiment analysis output). It is incomplete for an AI agent to fully understand what to expect.
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% for the single parameter 'url', so the baseline is 3. The description adds context about main content and sentiment but does not enhance understanding of the parameter beyond what the schema provides.
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 specifies the verb 'extract' and 'analyze' and the resource 'web page', clearly indicating it extracts main content and analyzes sentiment. It distinguishes from sibling tools like content_summarizer by including sentiment analysis, but could be more explicit about what 'main content' means.
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 is provided on when to use this tool versus alternatives such as multi_site_search or content_summarizer. The description does not mention exclusions or preferred contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fact_checkerA
Verify claims by searching multiple authoritative sources with credibility analysis and evidence extraction
| Name | Required | Description | Default |
|---|---|---|---|
| claim | Yes | The claim or statement to verify | |
| sources | No | Specific authoritative sources to check (e.g., ["wikipedia.org", "bbc.com", "reuters.com"]) | |
| confidenceThreshold | No | Minimum confidence level for verification (0.0-1.0) | |
| timeframe | No | Time range for search results | y1 |
| maxResults | No | Maximum results per source | |
| includeEvidence | No | Include extracted evidence snippets |
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. It describes the process (searching, analyzing credibility, extracting evidence) but does not disclose specific behavioral traits such as rate limits, authentication needs, or output format. The description is adequate but lacks detail on what the tool returns.
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, front-loaded sentence that conveys the essential action and features without waste. Every word earns its place.
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 6 parameters, no output schema, and no annotations, the description is incomplete. It does not describe the return structure or provide guidance on when to use versus sibling tools. It covers the process but lacks details on results and limitations.
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% with each parameter described. The tool description adds context by framing the overall task (e.g., 'credibility analysis' relates to confidenceThreshold, 'evidence extraction' relates to includeEvidence), providing meaning beyond individual parameter descriptions.
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: 'Verify claims by searching multiple authoritative sources with credibility analysis and evidence extraction'. It uses a specific verb ('Verify') and resource ('claims'), and distinguishes itself from sibling tools like 'google_search' or 'multi_site_search' by focusing on verification rather than general search.
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 implies the use case for fact-checking claims but does not explicitly state when to use this tool over alternatives like 'google_search' or 'multi_site_search'. The context is clear, but no exclusions or alternative guidance are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
google_searchC
Search the web using Google Custom Search API with various filtering options
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Search query string | |
| fileType | No | File type to search for | |
| siteSearch | No | Search within a specific site (e.g., "example.com") | |
| dateRestrict | No | Date restriction for search results | |
| safe | No | Safe search level | |
| exactTerms | No | Terms that must appear exactly as specified | |
| excludeTerms | No | Terms to exclude from search results | |
| sort | No | Sort order for results | |
| gl | No | Country code for geolocation (e.g., "us", "uk") | |
| hl | No | Language code for interface (e.g., "en", "es") | |
| num | No | Number of results to return (1-10) | |
| start | No | Starting index for results (1-based) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It only mentions 'various filtering options' without detailing rate limits, authentication, result format, or any constraints. The agent gains little insight into how the tool behaves.
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, making it concise. While it gets straight to the point, it could benefit from front-loading key details like the API used, but overall it is brief and minimally informative.
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 has 12 parameters and no output schema or annotations, the description is insufficient. It lacks details on return values, pagination, error handling, and usage context, making it incomplete for effective agent decision-making.
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 the schema already documents all parameters. The description's mention of 'filtering options' adds no specific meaning beyond what the schema provides, resulting in a neutral value add.
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 performs web searches using Google Custom Search API with filtering options, which is specific and aligns with the name. However, it does not explicitly differentiate from sibling tools like academic_search or multi_site_search.
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 is provided on when to use this tool versus alternatives. The description lacks any context about appropriate use cases or when to avoid using it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
multi_site_searchB
Search across multiple specific websites simultaneously
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query | |
| sites | Yes | Array of websites to search (e.g., ["github.com", "stackoverflow.com"]) | |
| maxResults | No | Max results per site | |
| fileType | No | File type to search for |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only adds the word 'simultaneously' beyond the basic purpose, but does not mention authentication needs, rate limits, result aggregation behavior, or any side effects.
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 at 9 words, which is efficient but omits important context. It is not overly verbose, but at the expense of completeness and usage guidance.
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 no output schema and 4 parameters (one with enum), the description does not explain return format, error handling, or any constraints beyond basic purpose. It is insufficient for an agent to fully understand tool behavior.
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 adds no additional meaning beyond what the input schema already provides for each parameter (query, sites, maxResults, fileType).
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 'Search across multiple specific websites simultaneously' clearly states the action (search), the resource (multiple specific websites), and a key differentiator (simultaneously). It easily distinguishes this tool from siblings like google_search (general) and academic_search (academic).
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 like google_search or news_monitor. There is no mention of when not to use it, prerequisites, or context where it excels.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
news_monitorC
Monitor news and get alerts for specific topics
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | Topic to monitor | |
| sources | No | News sources to monitor (e.g., ["bbc.com", "cnn.com", "reuters.com"]) | |
| language | No | Language code (e.g., "en", "es") | en |
| country | No | Country code (e.g., "us", "uk") | us |
| maxResults | No | Maximum results to return | |
| dateRestrict | No | Date restriction for news | d7 |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description fails to disclose critical behaviors: does it continuously monitor or perform a single query? Does it actually send alerts or just return results? This is a significant gap.
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 short (one sentence), but it is vague and could be more precise. It front-loads the main idea but lacks necessary details.
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?
With 6 parameters and no output schema or annotations, the description is insufficient. It does not clarify the return format, continuous vs one-time behavior, or how 'alerts' work, leaving significant ambiguity for the agent.
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 the baseline is 3. The description adds no extra meaning beyond the schema; it merely restates the tool's purpose without explaining parameter relationships or usage nuances.
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 states the tool monitors news and gets alerts, but 'monitor' implies continuous polling while the schema suggests a one-time query with maxResults and dateRestrict. The purpose is vaguely clear but lacks specificity and differentiation from sibling tools like google_search.
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 (e.g., google_search for general news, academic_search for scholarly). No scenarios or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
research_assistantC
Comprehensive research assistant with multi-step workflows, source synthesis, and structured report generation
| Name | Required | Description | Default |
|---|---|---|---|
| researchTopic | Yes | The main research topic or question to investigate | |
| researchType | No | Type of research to conduct | comprehensive |
| depth | No | Research depth level | standard |
| sources | No | Specific sources to include in research (optional) | |
| excludeSources | No | Sources to exclude from research | |
| timeframe | No | Time range for research results | y1 |
| maxSourcesPerType | No | Maximum sources per source type | |
| includeCitations | No | Include detailed citations and source tracking | |
| generateReport | No | Generate structured research report | |
| focusAreas | No | Specific areas to focus research on (e.g., ["methodology", "findings", "implications"]) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only mentions abstract concepts like 'multi-step workflows' and 'source synthesis' without concrete details on side effects, permissions, rate limits, or internal processes. The agent cannot anticipate costs, time, or data handling practices.
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 conveys the essence, but it is not structured with any detail. While concise, it does not earn its place fully as it omits critical information. A longer description with bullet points would be more helpful.
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 complexity (10 parameters, no output schema, no annotations), the description is insufficient. It fails to explain the output format, workflow steps, or any constraints. The agent lacks context to use the tool effectively, especially for a multi-step research assistant.
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 baseline is 3. The description adds no parameter-specific information beyond what the schema already provides. For example, it does not explain how 'depth' affects behavior or how 'focusAreas' narrow research.
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 states it is a 'comprehensive research assistant with multi-step workflows, source synthesis, and structured report generation', which clearly indicates a broad research tool that combines multiple functionalities. It distinguishes itself from sibling tools like google_search or fact_checker by implying a more integrated workflow, but lacks specific details on the exact scope.
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 is provided on when to use this tool versus alternatives. The description does not mention prerequisites, limitations, or conditions that would help an AI agent decide between research_assistant and sibling tools like academic_search or news_monitor.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_analyticsC
Analyze search trends and get insights from multiple search queries
| Name | Required | Description | Default |
|---|---|---|---|
| queries | Yes | Array of search queries to analyze | |
| timeRange | No | Time range for trend analysis | month |
| maxResults | No | Maximum results per query |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It does not disclose rate limits, authentication needs, whether the operation is read-only, or what happens with invalid inputs. The description is too brief to compensate for the lack of annotations.
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, front-loaded sentence that efficiently conveys the core purpose. It is concise with no wasted words, though it could benefit from more detail.
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 complexity (3 parameters, no output schema), the description is incomplete. It does not explain what kind of insights are returned, the format, or any limitations. For a tool that analyzes multiple queries, more context is needed for an AI agent to use it effectively.
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 input schema has 100% description coverage, so the baseline is 3. However, the description adds no additional meaning beyond the schema; it simply restates the purpose without detailing parameters. It does not clarify the expected format or usage of queries, timeRange, or maxResults beyond what the schema already provides.
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 that the tool analyzes search trends and provides insights from multiple queries. It distinguishes itself from sibling tools like google_search (raw results) and search_trends (possibly a different focus), though not explicitly.
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 is given on when to use this tool versus alternatives. With siblings like academic_search, fact_checker, and news_monitor, the description lacks context for choosing among them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_trendsC
Track and analyze search interest trends over time with predictive insights and emerging topic discovery
| Name | Required | Description | Default |
|---|---|---|---|
| topics | Yes | Array of topics to track trends for (1-5 topics) | |
| timeframe | No | Time period to analyze (1M=1 month, 3M=3 months, etc.) | 6M |
| region | No | Geographic region for trend analysis (country code like US, GB, CA) | US |
| category | No | Category filter for more targeted trend analysis | all |
| includePredictions | No | Include trend prediction and forecasting | |
| relatedTopics | No | Discover and include related trending topics |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only mentions tracking and analysis, but fails to specify whether the tool is read-only, how it handles predictions, or any side effects or limitations.
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 front-loads the core purpose. It is efficient, but could be slightly more structured to include differentiating details without adding length.
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 trend analysis and the lack of an output schema, the description is too brief. It does not explain what the tool returns, how to interpret predictions, or how the 'relatedTopics' and 'includePredictions' parameters affect results.
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 baseline is 3. The description does not add any parameter-specific meaning beyond what the schema already provides, but the schema itself is detailed enough.
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: tracking and analyzing search interest trends with predictive insights. However, it does not differentiate from the sibling 'search_analytics' tool, leaving ambiguity about when each should be used.
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 is provided on when to use this tool versus alternatives like 'search_analytics' or other sibling tools. The description lacks any context about appropriate use cases or prerequisites.
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.
10 tool updates
v1.0.0- First observed
academic_search - First observed
content_summarizer - First observed
extract_content - First observed
fact_checker - First observed
google_search - First observed
multi_site_search - First observed
news_monitor - First observed
research_assistant - First observed
search_analytics - First observed
search_trends
TDQS
Most tools have distinct purposes (e.g., academic_search vs. google_search), but some overlap exists between content_summarizer and extract_content, and between search_analytics and search_trends. Descriptions help clarify, but an agent might occasionally misselect.
Tool names use a consistent snake_case format, but the pattern varies: some are verb_noun (extract_content), others are noun_noun (search_trends) or noun (fact_checker). The naming is clear and readable overall.
With 10 tools, the server is well-scoped for search and research tasks. Each tool addresses a specific need without being too many or too few.
The tool set covers a wide range of search-related operations: general search, academic search, multi-site search, content extraction, fact-checking, news monitoring, research synthesis, and trend analysis. This is comprehensive for a search MCP server.
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
MCP server for Google search results via SERP API
Live AI-native web search with citations. One tool for every MCP client. Flat per-request pricing.
One MCP for the Web. Easily search, crawl, navigate, and extract websites without getting blocked.…
MCP server for web extraction and rendering via AceDataCloud WebExtrator
Appeared in Searches
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/1999AZZAR/Google-Search-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server