@semidark/mcp-litellm-searxng
Provides web search capabilities through a LiteLLM proxy backed by SearXNG, enabling AI agents to search the web and retrieve results.
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., "@@semidark/mcp-litellm-searxngsearch for latest developments 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.
@semidark/mcp-litellm-searxng
MCP server for searching the web through a LiteLLM proxy's SearXNG-backed search endpoint.
Installation
No local installation required — the server is executed on-demand via npx:
{
"mcp": {
"azurelit-search": {
"type": "local",
"command": ["npx", "-y", "@semidark/mcp-litellm-searxng"],
"environment": {
"LITELLM_SEARCH_URL": "https://your-litellm-proxy/v1/search/searxng-search",
"LITELLM_API_KEY": "sk-your-key",
"LITELLM_TIMEOUT_MS": "30000"
}
}
}
}With OpenCode, you can usually reuse your existing secret file:
{
"mcp": {
"azurelit-search": {
"type": "local",
"command": ["npx", "-y", "@semidark/mcp-litellm-searxng"],
"environment": {
"LITELLM_SEARCH_URL": "https://litellm-proxy.example.com/v1/search/searxng-search",
"LITELLM_API_KEY": "{file:~/.secrets/azure-lit.key}",
"LITELLM_TIMEOUT_MS": "30000"
}
}
}
}Related MCP server: mcp-searxng
Development
Run the server locally:
npm startRun the integration test harness:
LITELLM_SEARCH_URL="https://your-litellm-proxy/v1/search/searxng-search" \
LITELLM_API_KEY="sk-your-key" \
npm testnpm test is an integration test against a real LiteLLM endpoint. It does not mock the network and fails fast if LITELLM_SEARCH_URL or LITELLM_API_KEY is missing.
Environment Variables
Variable | Required | Default | Description |
| Yes | — | Full URL to the LiteLLM search endpoint |
| Yes | — | Bearer token for API authentication |
| No |
| Request timeout in milliseconds |
Tools
web_search
Search the web using the configured LiteLLM proxy search backend.
Parameters:
query(string, required): Search querymax_results(number, optional, default 10): Max results to return (1–50)
Returns:
text output formatted for chat clients
structuredContent.resultsas the raw LiteLLM result array
License
MIT
Available Tools
1 toolweb_searchWeb SearchA
Search the web using the LiteLLM proxy's configured search backend. Returns ranked search results with titles, URLs, snippets, and dates.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query string | |
| max_results | No | Maximum number of results to return (default: 10) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions using a 'configured search backend' and describes the return format but does not disclose potential side effects, authentication needs, or error conditions. It is adequate but not rich.
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?
Two sentences, efficiently conveying purpose and output. No extraneous information, front-loaded with the action.
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 simple search tool with full schema coverage and no output schema, the description covers core functionality well. It mentions the backend and return fields. However, it omits edge cases like empty results or errors, but this is acceptable for the simplicity.
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 additional meaning beyond what the schema already provides for the parameters. It does not explain query syntax or max_results behavior further.
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 verb 'Search' and the resource 'the web', and specifies what is returned (ranked results with titles, URLs, snippets, dates). There are no sibling tools, so differentiation is not needed.
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 or when not to use this tool, nor any alternatives mentioned. The description simply states what it does without context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
1 tool update
v1.0.1- First observed
web_search
TDQS
With only one tool, there is no possibility of confusion between tools. The single tool has a clear, distinct purpose.
The sole tool 'web_search' follows a clear verb_noun pattern. Consistency is not an issue with a single tool.
A single tool is minimal but acceptable for a focused search server. However, it feels thin compared to typical MCP servers.
The server provides exactly what its name implies: web search. For a narrow-purpose tool, it covers the core functionality without obvious gaps.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Provides AI assistants with access to Seltz's powerful Web Search capabilities.
LLM-ready web search + instant answers + URL-to-clean-text fetch for agents and RAG.
Enable AI assistants to perform web searches using Perplexity's Sonar Pro.
The best web search for your AI Agent
Related MCP Servers
- AlicenseAqualityDmaintenanceEnables AI assistants to perform web searches and read URL content via a SearXNG instance.218MIT
- AlicenseNot gradedqualityCmaintenanceIntegrates SearXNG API to give AI assistants web search and URL reading capabilities.9MIT
- AlicenseAqualityBmaintenanceEnables local LLMs to search the web and fetch clean content from URLs without API keys, using SearxNG and Mozilla Readability.236MIT
- FlicenseNot gradedqualityDmaintenanceEnables web search and content scraping from multiple engines via a local SearXNG instance, allowing AI assistants to retrieve and extract web content.1-
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/semidark/mcp-litellm-searxng'
If you have feedback or need assistance with the MCP directory API, please join our Discord server