Provides web search capabilities through SearXNG, enabling searches across multiple search engines with category filtering, language selection, time-based filtering, autocomplete suggestions, and access to instance configuration and health monitoring.
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., "@SearXNG MCP Server search for recent developments in quantum computing"
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.
A Model Context Protocol (MCP) server that integrates with SearXNG, providing powerful web search capabilities to MCP clients like Claude Desktop, Cline, and other MCP-compatible applications.
š Web Search: Search across multiple search engines aggregated by SearXNG
šÆ Category Filtering: Filter by categories (general, images, videos, news, etc.)
š Multi-Engine: Query specific search engines or use them all
š Localization: Search in different languages
ā° Time Filtering: Filter results by time range (day, month, year)
š”ļø Safe Search: Configurable safe search levels
š” Autocomplete: Get search suggestions for query completion
š§ Configuration Access: Query SearXNG instance capabilities
š„ Health Monitoring: Check instance health status
Related MCP server: SearXNG MCP Server
Python 3.10 or higher
A running SearXNG instance (local or remote)
An MCP client (e.g., Claude Desktop, Cline)
Clone the repository:
git clone https://github.com/martinchen448/searxng-mcp-server.git
cd searxng-mcp-serverInstall the package:
pip install -e .pip install searxng-mcp-serverAdd to your Claude Desktop configuration file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
For Local Instance (Recommended):
{
"mcpServers": {
"searxng": {
"command": "python",
"args": ["-m", "searxng_mcp_server"],
"env": {
"SEARXNG_BASE_URL": "http://localhost:8080/",
"SEARXNG_VERIFY_SSL": "false"
}
}
}
}For Public Instance:
{
"mcpServers": {
"searxng": {
"command": "python",
"args": ["-m", "searxng_mcp_server"],
"env": {
"SEARXNG_BASE_URL": "https://searx.be",
"SEARXNG_VERIFY_SSL": "true"
}
}
}
}Add to your MCP settings file:
Path: <User Directory>/.config/Code/User/globalStorage/rooveterinaryinc.roo-cline/settings/mcp_settings.json
For Local Instance (Recommended):
{
"mcpServers": {
"searxng": {
"command": "python",
"args": ["-m", "searxng_mcp_server"],
"env": {
"SEARXNG_BASE_URL": "http://localhost:8080/",
"SEARXNG_VERIFY_SSL": "false"
}
}
}
}For Public Instance:
{
"mcpServers": {
"searxng": {
"command": "python",
"args": ["-m", "searxng_mcp_server"],
"env": {
"SEARXNG_BASE_URL": "https://searx.be",
"SEARXNG_VERIFY_SSL": "true"
}
}
}
}SEARXNG_BASE_URL (required): Base URL of your SearXNG instance
Example: https://search.example.com or http://localhost:8888
SEARXNG_VERIFY_SSL (optional): Whether to verify SSL certificates
Default: true
Set to false for self-signed certificates or local development
Before using with Claude Desktop or Cline, test your server with the MCP Inspector.
Use the provided convenience scripts:
Windows (Command Prompt):
run-inspector.batWindows (PowerShell):
.\run-inspector.ps1Linux/macOS:
chmod +x run-inspector.sh
./run-inspector.shOr run directly:
# Set environment variable first
export SEARXNG_BASE_URL=https://searx.be # Linux/macOS
set SEARXNG_BASE_URL=https://searx.be # Windows CMD
$env:SEARXNG_BASE_URL="https://searx.be" # Windows PowerShell
# Then run inspector
npx @modelcontextprotocol/inspector python -m searxng_mcp_serverThe Inspector will open in your browser (typically http://localhost:5173) where you can:
Test all tools interactively
View real-time request/response logs
Inspect resources
Debug connection issues
For detailed testing instructions, see Testing with MCP Inspector.
If you don't have a SearXNG instance, you can:
Find public instances at: https://searx.space/
Example public instances:
Important Notes:
Public instances may have rate limits or restrictions
Some public instances block automated requests (HTTP 403 errors)
For reliable operation, consider running your own instance
If you encounter 403 errors, try a different public instance or set up a local instance
Using Docker (recommended):
docker pull searxng/searxng
docker run -d -p 8888:8080 \
-v "${PWD}/searxng:/etc/searxng" \
-e "BASE_URL=http://localhost:8888/" \
-e "INSTANCE_NAME=my-instance" \
searxng/searxngSee the SearXNG documentation for more deployment options.
Perform web searches across multiple search engines.
Parameters:
query (required): Search query string
categories (optional): Array of categories (e.g., ["general", "images", "news"])
engines (optional): Array of specific engines (e.g., ["google", "bing"])
language (optional): Language code (default: "en")
page (optional): Page number for pagination (default: 1)
time_range (optional): Filter by time ("day", "month", "year")
safesearch (optional): Safe search level (0=off, 1=moderate, 2=strict)
Example:
{
"query": "Python async programming",
"categories": ["general"],
"language": "en",
"time_range": "year",
"safesearch": 0
}Get autocomplete suggestions for a query prefix.
Parameters:
query (required): Query prefix
language (optional): Language code (default: "en")
Example:
{
"query": "machine learn",
"language": "en"
}Check if the SearXNG instance is accessible and healthy.
Parameters: None
Get the configuration and capabilities of the SearXNG instance.
Parameters: None
Returns information about:
Available search engines
Enabled categories
Supported languages
Active plugins
Instance settings
Access to the SearXNG instance configuration as a persistent resource.
Health status of the SearXNG instance as a persistent resource.
Ask your MCP client:
Search for "best practices for Python async programming"Ask your MCP client:
Search for images of "northern lights" from the past monthThe server will use:
{
"query": "northern lights",
"categories": ["images"],
"time_range": "month"
}Ask your MCP client:
Find recent news about artificial intelligenceThe server will use:
{
"query": "artificial intelligence",
"categories": ["news"],
"time_range": "day"
}Ask your MCP client:
Get search suggestions for "climate"Available categories in SearXNG:
general - General web search
images - Image search
videos - Video search
news - News articles
music - Music search
files - File search
social media - Social media posts
science - Scientific articles
it - IT/Programming resources
map - Maps and locations
# Clone the repository
git clone https://github.com/martinchen448/searxng-mcp-server.git
cd searxng-mcp-server
# Install with dev dependencies
pip install -e ".[dev]"pytest# Format code with black
black src tests
# Lint with ruff
ruff check src tests
# Type checking with mypy
mypy srcsearxng-mcp-server/
āāā src/
ā āāā searxng_mcp_server/
ā āāā __init__.py
ā āāā server.py # MCP server implementation
ā āāā client.py # SearXNG API client
āāā tests/
ā āāā test_server.py
ā āāā test_client.py
āāā pyproject.toml
āāā README.mdIf you encounter connection errors:
Verify the SearXNG URL: Ensure SEARXNG_BASE_URL is correct and accessible
Check SSL certificates: For self-signed certificates, set SEARXNG_VERIFY_SSL=false
Test the instance: Visit the URL in your browser to ensure it's running
Check firewall: Ensure no firewall is blocking the connection
For self-signed certificates or local development:
{
"env": {
"SEARXNG_BASE_URL": "http://localhost:8888",
"SEARXNG_VERIFY_SSL": "false"
}
}If searches return no results:
Check instance configuration: Use the get_config tool to see available engines
Verify engines are enabled: Some instances may have limited engines
Try different categories: Some categories may not be available
Check instance logs: Review SearXNG logs for errors
Contributions are welcome! Please follow these steps:
Fork the repository
Create a feature branch (git checkout -b feature/amazing-feature)
Make your changes
Run tests and linting
Commit your changes (git commit -m 'Add amazing feature')
Push to the branch (git push origin feature/amazing-feature)
Open a Pull Request
This project is licensed under the MIT License - see the LICENSE file for details.
SearXNG - The privacy-respecting metasearch engine
Model Context Protocol - The protocol specification
Anthropic - For developing the MCP standard
SearXNG - Privacy-respecting metasearch engine
MCP Specification - MCP protocol documentation
Claude Desktop - Desktop application with MCP support
š Report bugs
š” Request features
š Documentation
See CHANGELOG.md for version history and changes.
Get the configuration of the SearXNG instance.
This tool retrieves the SearXNG instance configuration including available search engines, enabled categories, supported locales, plugins, and instance settings. Useful for understanding what capabilities are available.
Use this when you need to:
Discover available search engines
See what categories are enabled
Check supported languages/locales
Understand instance capabilities and settings
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 clearly indicates this is a read-only operation ('retrieves') and specifies what data is returned, but lacks details on potential rate limits, authentication requirements, error conditions, or response format. The description adds useful context about the scope of configuration data but doesn't fully compensate for the absence 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 well-structured and front-loaded with the core purpose in the first sentence. Each subsequent sentence and bullet point adds specific value without redundancy. The bullet points efficiently organize usage scenarios, making the description easy to scan while maintaining complete information.
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?
For a zero-parameter read-only tool with no output schema, the description provides comprehensive information about what configuration data is retrieved and when to use it. However, it doesn't describe the response format or structure, which would be helpful given the absence of an output schema. The description covers the essential context but leaves some ambiguity about what the return data looks like.
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 tool has 0 parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, and instead focuses on explaining what configuration data will be retrieved, which adds value beyond the empty schema.
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 specific action ('retrieves') and resource ('SearXNG instance configuration'), listing concrete components like search engines, categories, locales, plugins, and settings. It distinguishes from siblings like 'search' (which performs searches) and 'get_suggestions' (which provides query suggestions) by focusing on configuration discovery rather than search operations.
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 explicitly provides four bullet points detailing when to use this tool: to discover available search engines, see enabled categories, check supported languages/locales, and understand instance capabilities. It implicitly distinguishes from 'search' (which is for executing searches) and 'get_suggestions' (for query autocompletion) by focusing on configuration discovery rather than search functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get search suggestions/autocomplete for a query prefix.
This tool provides search suggestions based on a partial query, similar to autocomplete functionality in search engines. Useful for discovering related searches or expanding on a topic.
Use this when you need to:
Get autocomplete suggestions for a search
Discover related search terms
Help users formulate better search queries
Explore variations of a search topic
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The query prefix to get suggestions for | |
| language | No | Language code for suggestions (default: 'en') | en |
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 adequately describes the core functionality (autocomplete suggestions) but lacks details about rate limits, response format, error conditions, or performance characteristics. The description doesn't contradict any annotations since none exist.
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 well-structured with a clear opening statement followed by a purpose explanation and specific usage guidelines. While slightly verbose in the bulleted list, every sentence adds value and the information is front-loaded appropriately for an AI agent.
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?
For a read-only tool with no annotations and no output schema, the description provides adequate context about what the tool does and when to use it. However, it lacks information about return values, error handling, and operational constraints that would be helpful given the absence of structured metadata.
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 both parameters thoroughly. The description adds minimal value beyond the schema by mentioning 'query prefix' and 'search suggestions' context, but doesn't provide additional syntax, format, or constraint details. 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 with specific verbs ('Get search suggestions/autocomplete') and resource ('for a query prefix'), distinguishing it from siblings like 'search' by focusing on autocomplete rather than full search results. It explicitly mentions similarity to search engine autocomplete functionality.
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 explicit usage scenarios in a bulleted list: getting autocomplete suggestions, discovering related terms, helping formulate queries, and exploring search variations. It clearly indicates when to use this tool versus alternatives like 'search' by focusing on partial queries and discovery.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the health status of the SearXNG instance.
This tool verifies that the SearXNG instance is running and accessible. Useful for diagnostics and ensuring the search service is operational before performing searches.
Use this when you need to:
Verify the SearXNG instance is accessible
Diagnose connection issues
Check service availability before searching
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool checks health status and accessibility, implying a read-only, non-destructive operation useful for diagnostics. However, it lacks details on error handling, response format, or potential side effects like network timeouts, leaving some behavioral aspects unclear.
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 well-structured and front-loaded with the core purpose, followed by usage guidelines in a bulleted list. It avoids unnecessary details, but the bulleted list could be slightly more concise (e.g., by combining related points), though overall it's efficient and easy to scan.
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 simplicity (0 parameters, no output schema, no annotations), the description is reasonably complete. It explains the purpose, usage, and context effectively. However, without an output schema, it could benefit from briefly mentioning what the health check returns (e.g., status codes or messages), slightly limiting completeness for diagnostics.
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 tool has 0 parameters with 100% schema description coverage, so the schema fully documents the input. The description appropriately adds no parameter-specific information, as none are needed, maintaining clarity without redundancy. This meets the baseline for tools with no parameters.
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 with specific verbs ('check', 'verifies') and resource ('SearXNG instance'), explicitly distinguishing it from sibling tools like 'search' by focusing on health verification rather than search operations. It directly answers what the tool does without being tautological.
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 explicit usage scenarios in a bulleted list (e.g., 'Verify the SearXNG instance is accessible', 'Diagnose connection issues'), clearly indicating when to use this tool. It implicitly distinguishes from alternatives like 'search' by specifying it's for pre-search availability checks, though it doesn't explicitly name sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the web using SearXNG search engine.
This tool performs web searches across multiple search engines aggregated by SearXNG. You can filter by categories (general, images, videos, news, etc.), specific engines, language, and time range. Returns comprehensive results including titles, URLs, content snippets, and metadata.
Use this when you need to:
Search for information on the web
Find recent news or articles
Search for images or videos
Get diverse results from multiple search engines
Research a topic across different sources
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The search query string | |
| categories | No | List of categories to search (e.g., ['general', 'images', 'news']). Available: general, images, videos, news, music, files, social media, science, it, map | |
| engines | No | List of specific search engines to use (e.g., ['google', 'bing', 'duckduckgo']) | |
| language | No | Language code for results (default: 'en') | en |
| page | No | Page number for pagination (default: 1) | |
| time_range | No | Time range filter for results | |
| safesearch | No | Safe search level: 0=off, 1=moderate, 2=strict (default: 0) |
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 describes what the tool does ('performs web searches across multiple search engines aggregated by SearXNG') and what it returns ('comprehensive results including titles, URLs, content snippets, and metadata'), but lacks details on rate limits, authentication needs, error handling, or pagination behavior beyond the 'page' parameter. It adequately covers basic behavior but misses advanced operational context.
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 well-structured and appropriately sized. It starts with a clear purpose statement, followed by a brief explanation of functionality, and ends with a bulleted list of use cases. Every sentence adds value without redundancy, and the information is front-loaded for quick comprehension.
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 (7 parameters, no output schema, no annotations), the description is reasonably complete. It explains the tool's purpose, usage guidelines, and basic behavior, but lacks details on output format specifics, error conditions, or advanced behavioral traits like rate limiting. It compensates well for the absence of annotations and output schema, though not fully.
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 7 parameters thoroughly. The description adds marginal value by mentioning filtering capabilities ('filter by categories, specific engines, language, and time range') and listing some category examples, but doesn't provide additional syntax, format details, or constraints beyond what the schema specifies. 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 with specific verbs ('Search the web using SearXNG search engine') and resources ('across multiple search engines aggregated by SearXNG'). It distinguishes itself from sibling tools (get_config, get_suggestions, health_check) by focusing on web search functionality rather than configuration retrieval, suggestions, or system health checks.
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 explicit guidance on when to use this tool through a bulleted list: 'Use this when you need to: - Search for information on the web - Find recent news or articles - Search for images or videos - Get diverse results from multiple search engines - Research a topic across different sources'. This clearly defines appropriate use cases without mentioning alternatives, which is sufficient given the tool's distinct purpose among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
get_configget_suggestionshealth_checksearchEach tool has a clearly distinct purpose with no overlap: get_config retrieves instance configuration, get_suggestions provides autocomplete, health_check verifies service status, and search performs actual web searches. The descriptions reinforce these distinct roles, making misselection unlikely.
All tool names follow a consistent verb_noun pattern with snake_case: get_config, get_suggestions, health_check, and search. The naming is predictable and readable throughout the set.
Four tools is reasonable for a search server, covering configuration, suggestions, health, and core search functionality. It feels slightly minimal but well-scoped, as each tool serves a clear purpose without redundancy.
The tool set covers the essential operations for interacting with a SearXNG instance: checking health, retrieving configuration, getting suggestions, and performing searches. A minor gap might be the lack of tools for managing search history or preferences, but core workflows are fully supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Serper MCP ā wraps the Serper Google Search API (serper.dev)
Search and install 4,000+ security-scanned MCP servers from inside any MCP-aware AI client.
Docs: https://docs.keenable.ai/mcp-server Keenable is a free, remote MCP server that gives agents access to the web index. Search the web with ranked results and date/site filters, then fetch any indexed page as clean markdown. Works out of the box with no account or API key.
Scrape, crawl and search the web for AI agents via MCP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/martinchen448/searxng-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
