Skip to main content
Glama
mason99-stack

beacon

by mason99-stack
OverviewSchemaRelated ServersScoreDiscussions
Python
Remote

beacon

A zero-config web search MCP server for any MCP client (opencode, Claude Desktop, Cursor, etc.).

Gives your local models the ability to search the web and read page content — no API keys, no Docker, no setup beyond pip install.

What it gives you

Two MCP tools:

Tool

Description

beacon_search(query, max_results=5)

Web search via DuckDuckGo. Returns {title, url, snippet} hits.

beacon_fetch(url, max_chars=8000)

Fetches a URL and returns its main readable text (HTML-stripped, boilerplate removed).

Related MCP server: mcp-ddg-research

Install

git clone <your-fork-url> beacon
cd beacon
python3 -m venv .venv
.venv/bin/pip install -e .

Register with an MCP client

opencode

Add to your opencode.json:

{
  "mcp": {
    "beacon": {
      "type": "local",
      "command": ["/absolute/path/to/beacon/.venv/bin/beacon-mcp"]
    }
  }
}

Claude Desktop

Add to claude_desktop_config.json:

{
  "mcpServers": {
    "beacon": {
      "command": "/absolute/path/to/beacon/.venv/bin/beacon-mcp"
    }
  }
}

Manual testing (CLI)

.venv/bin/beacon search "python async patterns"
.venv/bin/beacon fetch https://example.org

Configuration (optional, via env vars)

Variable

Default

Purpose

BEACON_TIMEOUT

15

HTTP timeout (seconds) for fetch

BEACON_USER_AGENT

Firefox-like string

User-Agent for outbound requests

BEACON_LOG_LEVEL

INFO

Logging verbosity

No state is written to disk. No database. No API keys required.

Development

.venv/bin/pip install -e ".[dev]"
.venv/bin/python -m pytest -v

License

MIT.

Available Tools

2 tools
beacon_fetchA

Fetch a URL and return its main readable text content.

Extracts the article/page body (drops navigation, ads, boilerplate). Returns plain text, not HTML.

Args: url: An http(s) URL. max_chars: Truncate content to protect context budget (default 8000).

Returns: {"url", "title", "content"} or None if the URL cannot be fetched.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYes
max_charsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations provided, the description fully takes on the burden of behavioral transparency. It discloses that it drops navigation/ads/boilerplate, returns plain text not HTML, truncates via max_chars, and returns None on fetch failure. These behavioral traits go well beyond the basic schema and give the agent a realistic expectation of the tool's behavior.

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 well-structured: a concise opening claim, followed by a brief detail on extraction, a note on return type, then a simple Args/Returns list. Every sentence contributes useful information, with zero redundancy. It is appropriately sized for the tool's complexity.

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?

Given the tool's simplicity (2 params, 1 required, no enums), the description is fully complete. It covers the purpose, behavior, parameters, return format, and failure case. The presence of an output schema is not strictly necessary because the description already states the return shape ('{"url", "title", "content"} or None').

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?

Since schema description coverage is 0%, the description must fully explain parameters. It does: url is specified as an http(s) URL, and max_chars is explained as a truncation limit to protect context budget with a default of 8000. This adds meaningful semantics that the bare schema properties ('url', 'max_chars') lack.

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?

Description states a specific verb ('Fetch a URL') and resource ('return its main readable text content'), clearly distinguishing it from the sibling beacon_search tool which searches rather than fetches. The first sentence is unambiguous about the tool's action and output.

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 clearly implies the tool is for retrieving URL content, which implicitly differentiates it from beacon_search. However, it does not explicitly state 'use this when you have a URL' or provide exclusions/alternatives, so it falls just short of a perfect score. The context is clear enough for an agent to infer the appropriate use case.

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 observedbeacon_fetch
    • First observedbeacon_search
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.7/5.0
Disambiguation5/5

The two tools have clearly distinct purposes: one searches the web for URLs and the other fetches a specific URL's content. There is no overlap or confusion between them.

Naming Consistency5/5

Both tools use a consistent 'beacon_' prefix followed by a simple verb ('search' and 'fetch'), forming a predictable and coherent naming pattern.

Tool Count3/5

With only two tools, the server feels minimally scoped for a web search/fetch utility. While each tool is essential, the count is borderline and may leave users wanting additional capabilities like URL validation or cached results.

Completeness5/5

The server provides a complete workflow: search for URLs, then fetch and read content. It covers the core domain of web searching and extraction without obvious gaps or dead ends.

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

  • DuckDuckGo Search MCP

    OEvortex
    A
    license
    A
    quality
    A
    maintenance
    A privacy-friendly MCP server that enables web searches and URL content extraction using DuckDuckGo, allowing AI assistants to access real-time web information without API keys.
    1
    665
    42
    Apache 2.0

  • local-websearch-mcp

    dr34dl10n
    A
    license
    Not graded
    quality
    D
    maintenance
    Small Python MCP server that provides web search and page fetching tools via DuckDuckGo, requiring no API key.
    Apache 2.0

  • EZ Web Search MCP Server

    Gnarus-G
    F
    license
    A
    quality
    D
    maintenance
    A simple MCP server that provides web search functionality via DuckDuckGo, returning titles, URLs, and descriptions for results. Configurable result limit.
    1
    -

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/mason99-stack/beacon-mcp'

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