Skip to main content
Glama
DumbGreenFish

greenfish-webtools-mcp

by DumbGreenFish
OverviewSchemaRelated ServersScoreDiscussions
Python
Hybrid

Forks Stargazers Issues GPL License

About The Project

greenfish-webtools-mcp is a Model Context Protocol server that equips AI assistants with live web access. It exposes two tools: web search and URL content extraction.

The key design choice is that this server does not talk to any proprietary search API. Instead, it delegates all search work to your own SearXNG instance — a self-hosted, actively maintained meta-search engine that aggregates results from multiple search providers and exposes a stable JSON API that won't change or be deprecated without notice. You spin up SearXNG, this server connects to it and passes results straight to the model.

greenfish_websearch sends a query to SearXNG and returns a ranked, deduplicated list of results. greenfish_fetch_url fetches a specific page and returns its main readable content, stripped of navigation, ads, and boilerplate using trafilatura.

Related MCP server: noapi-google-search-mcp

Built With

Python SearXNG uv

Getting Started

Before anything else, make sure you have Python 3.10+ and uv installed. You will also need a running SearXNG instance with JSON output enabled. The quickest way to get one is via Docker:

docker run -d --name searxng -p 1818:8080 searxng/searxng

After that, open the SearXNG admin interface, go to Preferences → General, and enable json as an output format. Alternatively, find settings.yml in the SearXNG container and add json to the search.formats list, then restart the container.

Now clone this repository and install the Python dependencies:

git clone https://github.com/DumbGreenFish/GreenFishWebtoolsMCP.git
cd greenfish-webtools-mcp
uv sync

That's it. No API keys, no accounts.

Usage

You can run greenfish-webtools-mcp either as a local stdio MCP server or as a regular HTTP server.

Stdio

Register the server in your MCP client configuration file. The example below works for Claude Desktop and most other clients that accept the standard JSON format:

{
  "mcpServers": {
    "greenfish-webtools": {
      "command": "uv",
      "args": [
        "--directory",
        "/path/to/greenfish-webtools-mcp",
        "run",
        "app-stdin.py"
      ],
      "env": {
        "SEARXNG_URL": "http://127.0.0.1:1818/search"
      }
    }
  }
}

Replace /path/to/greenfish-webtools-mcp with the actual path to the cloned repository on your machine, and adjust SEARXNG_URL to match the address where your SearXNG instance is running.

HTTP server

Alternatively, you can run the MCP server as a regular HTTP server using app.py:

uv run app.py

By default, the MCP endpoint is available at:

http://localhost:1235/mcp

For MCP clients that support remote HTTP servers, the configuration can look like this:

{
  "mcpServers": {
    "greenfish-webtools": {
      "url": "http://localhost:1235/mcp"
    }
  }
}

Once connected using either method, the AI assistant will have access to greenfish_websearch and greenfish_fetch_url automatically.

Docker

To run the HTTP server with the bundled SearXNG instance, create .env and set SEARXNG_SECRET:

Then start the services with:

docker compose up

If you already have your own SearXNG instance, set SEARXNG_URL in .env to the address of your SearXNG instance and use the plain Compose configuration instead:

docker compose -f docker-compose.plain.yml up

Roadmap

  • Support for additional SearXNG parameters (time range, search categories)

  • Configurable result ranking and deduplication strategy

  • Multi-language documentation

See the open issues for a full list of proposed features and known issues.

Contributing

Contributions are what make the open source community such an amazing place to learn, inspire, and create. Any contributions you make are greatly appreciated.

If you have a suggestion that would make this better, please fork the repo and create a pull request. You can also open an issue with the tag "enhancement". Don't forget to give the project a star — thanks!

License

Distributed under the GNU GPLv3 License. See LICENSE for more information.

Contact

Project Link: https://github.com/DumbGreenFish/GreenFishWebtoolsMCP

Acknowledgments

This project would not exist without SearXNG, which does all the actual search work. Thanks also to the authors of FastMCP, trafilatura, and httpx.

Available Tools

2 tools
fetch_urlA
Read-onlyIdempotent

Fetches a web page and returns its main readable content, stripped of navigation, ads and boilerplate. Use this to read the full text of a specific article or documentation page when you already have its URL.

ParametersJSON Schema
NameRequiredDescriptionDefault
paramsYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds that content is stripped of navigation and boilerplate, beyond annotations. No contradictions.

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?

Two sentences: first explains what the tool does, second gives usage guidance. No wasteful words, front-loaded with key information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only tool with an output schema and two well-described parameters, the description covers purpose, usage, and behavior adequately. No missing critical details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already provides clear descriptions for both 'url' and 'max_chars' parameters, so the description adds minimal parameter-specific value but does clarify the output quality (stripped content). Baseline 3.

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 it fetches a web page and returns main readable content, stripping boilerplate. It distinguishes from sibling 'websearch' by specifying 'when you already have its URL'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says to use this tool for reading a specific article or documentation page when you have the URL, implying not for search (which is the sibling tool's role).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

websearchA
Read-onlyIdempotent

Performs a web search and returns the results. This tool allows searching the live web for current information without requiring API keys. It is ideal for retrieving news, documentation, or general facts. Example: Use this tool when you need to find information about recent events or technical documentation.

ParametersJSON Schema
NameRequiredDescriptionDefault
paramsYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.9/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint, destructiveHint, idempotentHint, and openWorldHint, covering safety and idempotency. The description adds minor context about not requiring API keys, but does not go beyond what annotations imply. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is reasonably concise at five lines, including an example. However, there is some redundancy (e.g., 'Performs a web search' and 'allows searching the live web'), and the structure could be tightened without losing clarity.

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 description covers purpose, usage, and behavioral context (no API keys). With an output schema presumably present, it does not need to detail return values. It could be more complete by explicitly contrasting with 'fetch_url' or listing limitations, but overall it's adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema provides detailed descriptions for all five parameters, so baseline is 3. The description does not add additional meaning or context about parameters beyond what the schema already provides.

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 performs a web search and returns results, specifying it searches the live web for current information. It distinguishes itself from the sibling tool 'fetch_url' by being a search rather than a URL fetch, and provides concrete examples of use cases (news, documentation, facts).

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 gives clear context for when to use the tool (retrieving news, documentation, general facts) and includes an example (recent events, technical documentation). However, it does not explicitly state when not to use it or compare with the sibling 'fetch_url', missing an opportunity for clearer guidance.

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. 2 tool updatesv0.1.0
    • First observedfetch_url
    • First observedwebsearch
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0
Disambiguation5/5

The two tools have clearly distinct purposes: fetch_url retrieves content from a known URL, while websearch performs a search query. There is no overlap or ambiguity.

Naming Consistency5/5

Both tool names follow a consistent verb_noun pattern in snake_case: fetch_url and websearch (where 'web' is the noun and 'search' is the verb).

Tool Count4/5

With only 2 tools, the server is minimal but still reasonable for a basic web tools utility. It covers the essential functions of searching and fetching, though additional tools like list search results could be useful.

Completeness4/5

The server covers the basic web access workflow: search to find URLs, then fetch to read content. Minor gaps exist (e.g., no pagination or result filtering), but core functionality is present.

Maintenance

ActivityMaintained
ResponsivenessNo issues

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

Related MCP Servers

  • LLM Researcher

    Code-Hex
    F
    license
    Not graded
    quality
    D
    maintenance
    A lightweight MCP server that enables LLMs to search the web via DuckDuckGo, search GitHub code repositories, and extract clean content from web pages in LLM-friendly formats.
    8
    -

  • mult-fetch-mcp-server

    lmcc-dev
    A
    license
    A
    quality
    C
    maintenance
    An MCP server that enables AI assistants to fetch web content in multiple formats (HTML, JSON, text, Markdown) with intelligent content extraction, chunk management, and browser automation support.
    5
    52
    15
    MIT
  • Wick by wickproject

    Wickofficial

    wickproject
    F
    license
    Not graded
    quality
    A
    maintenance
    An MCP server that provides browser-grade web access for AI agents, using Chrome's actual network stack to bypass anti-bot protections and return clean markdown.
    8
    -

Latest Blog Posts

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/DumbGreenFish/GreenFishWebtoolsMCP'

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