SearXNG Control Plane MCP Server

by TheNovaNodes

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation2/5
The three engine control tools (set_engine_status, enable_engine, disable_engine) heavily overlap, with set_engine_status effectively combining the other two. This creates ambiguity about which tool to use for enabling/disabling an engine. The remaining tools are distinct but the redundancy lowers the overall clarity.
Naming Consistency4/5
All tool names follow a consistent verb_noun pattern with snake_case (inspect_settings, set_engine_status, enable_engine, disable_engine, test_search_api_health, restart_searxng_container). The only inconsistency is that set_engine_status and enable/disable_engine represent overlapping actions, but the naming convention itself is uniform.
Tool Count5/5
With six tools, the server is well-scoped for a control plane managing a SearXNG instance. Each tool covers a distinct area (settings inspection, engine status modification, health testing, container restart) without unnecessary bloat, making the count appropriate.
Completeness3/5
The surface covers core operations like inspecting settings, toggling engines, testing health, and restarting. However, it lacks lifecycle operations such as starting, stopping, or getting the container status, and there's no direct 'apply config' action. These gaps are notable for a control plane but not fatal.
Average 3.6/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It merely says 'Enable' without revealing side effects such as modifying settings.yml, whether a restart is needed, permissions required, or reversibility of the change.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a single summary line followed by a compact Args section. Every sentence is useful, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose and parameters, and an output schema exists, so return values are handled. However, it lacks usage guidance and behavioral side effects, making it adequate but incomplete for a mutation tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by explaining engine_name with an example ('duckduckgo') and settings_path as optional. It does not clarify what happens when settings_path is omitted, but it does add meaningful parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Enable a specific search engine in SearXNG settings.yml', providing a specific verb, resource, and file scope. It differentiates from disable_engine and inspect_settings, but overlaps conceptually with set_engine_status without explicitly distinguishing between them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It only documents the arguments and does not mention set_engine_status or disable_engine as related options, so the agent receives no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose side effects, but it only says 'Disable... in settings.yml'. It does not mention whether the change is persistent, reversible, requires a restart (e.g., via restart_searxng_container), or what happens if the engine name is invalid. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus an Args list with no filler or repetition of schema fields. Each element contributes to clarifying the operation, making it appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is minimal for a config-modifying tool. It fails to explain whether SearXNG needs a restart, if the engine must exist, or how the result is returned. With no annotations and no post-steps, the description is incomplete for safe agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema properties have no descriptions (0% coverage), so the description compensates by defining engine_name with an example ('duckduckgo') and explaining settings_path as 'Optional path to settings.yml'. This adds meaning beyond the bare schema, though it could be more explicit about defaults and validation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Disable a specific search engine in SearXNG settings.yml'—a specific verb (disable) and resource (search engine in a config file). This distinguishes it from sibling tools like enable_engine and set_engine_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 over alternatives. The description does not reference sibling tools, prerequisites, or post-conditions. It merely states the action and parameters, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states the action 'Restart' and the mechanism 'via subprocess', without detailing side effects, required permissions, potential downtime, or error behavior. It lacks meaningful transparency about operational consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: a one-sentence action statement followed by a brief Args block. Every piece of text contributes useful information, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one optional parameter, no required inputs, output schema present), the description adequately covers the core action and parameter semantics. However, it omits any operational context such as prerequisites (e.g., Docker running) or expected effects beyond the restart, leaving minor gaps for a full understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides minimal info for the single optional parameter 'container_name' with a default of null, and schema description coverage is 0%. The description compensates by explaining that the parameter is the Docker container name and defaults to SEARXNG_CONTAINER_NAME, adding clarity about the default behavior and the parameter's meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Restart the SearXNG Docker container via subprocess.' It uses a specific verb and resource, and it is distinguishable from sibling tools which focus on settings and engine status, not container lifecycle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, or any context such as when a restart is needed. The description only mentions the default container name parameter, but no prerequisites, exclusions, or conditions under which the tool should be invoked.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clearly states the core behavior (enable/disable in settings.yml) and notes the settings_path default via SEARXNG_SETTINGS_PATH, which is useful. However, it does not disclose whether changes persist across restarts, whether a restart/reload is required, or any permission/validation implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description leads with a crisp one-sentence purpose and then provides a compact, well-organized Args block. Every sentence adds value without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The parameter details are solid, and an output schema exists, reducing the need to describe return values. However, the tool is surrounded by enable_engine, disable_engine, and restart_searxng_container, yet the description does not clarify when to use this combined setter instead, nor whether a restart is required after modification. Given no annotations, this is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description's Args section thoroughly explains each parameter: engine_name with concrete examples, enabled as a boolean toggle, and settings_path as optional with a default. This fully compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb phrase ('Enable or disable') and clearly identifies the target resource ('a search engine in settings.yml'). However, it does not explicitly differentiate itself from sibling tools enable_engine and disable_engine, which likely have narrower, single-purpose behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the sibling enable_engine/disable_engine tools. There is no mention of preconditions, follow-up steps, or scenarios where this generic setter is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 does add behavioral context by explaining the default path behavior (defaults to SEARXNG_SETTINGS_PATH) and the read-only nature implied by 'inspect'. However, it does not explicitly state that the tool makes no modifications or what happens if the path is invalid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences. The primary purpose is stated first, followed by a clear argument explanation. No redundant content or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional param, no annotations, but with an output schema), the description adequately covers the essential function and the parameter. However, it lacks usage context and explicit behavioral guarantees (e.g., read-only disclosure), which are important for an agent to choose and invoke it safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no property descriptions (coverage 0%). The description compensates by explaining 'settings_path: Optional path to settings.yml. Defaults to SEARXNG_SETTINGS_PATH.' This adds meaning beyond the schema's bare type/title, clarifying optionality, purpose, and default behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Inspect SearXNG configuration settings and active/disabled engines from settings.yml.' It uses a specific verb ('inspect') and identifies the resource (configuration and engine status), distinguishing it from sibling tools that modify engines or restart the container.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention conditions like 'before enabling/disabling engines' or any exclusions. There is no explicit or implied usage context beyond the basic action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It discloses that a test query is issued and latency is measured, which is the core behavior. However, it does not mention side effects, authentication requirements, or error behavior. The description adds some value but lacks deeper context for a completely transparent disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct and well-structured: a one-sentence summary followed by a brief Args list. Every sentence adds value without redundancy, and the most critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, and the description covers its purpose and both parameters. Since an output schema exists, the description need not detail return values. Minor gaps, such as not mentioning error handling or prerequisites, are acceptable given the tool's simplicity and presence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the parameters. It does this effectively by defining 'url' as the base URL/endpoint and 'query' as the test query string, including their defaults. This fully clarifies the meaning beyond the raw schema properties.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Test SearXNG Search API health by issuing a test query and measuring latency.' It uses a specific verb ('test') and resource ('SearXNG Search API'), and is distinguishable from sibling tools that manage settings or engine status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a clear usage context: when you need to check the health/latency of a SearXNG search API. While it does not explicitly list exclusions or alternatives, the tool is the only health-check among its siblings, making the intended use evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![searxng-mcp-control MCP server](https://glama.ai/mcp/servers/TheNovaNodes/searxng-mcp-control/badges/card.svg)](https://glama.ai/mcp/servers/TheNovaNodes/searxng-mcp-control)

Score Badge

Copy to your README.md:

[![searxng-mcp-control MCP server](https://glama.ai/mcp/servers/TheNovaNodes/searxng-mcp-control/badges/score.svg)](https://glama.ai/mcp/servers/TheNovaNodes/searxng-mcp-control)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/TheNovaNodes/searxng-mcp-control'

If you have feedback or need assistance with the MCP directory API, please join our Discord server