Skip to main content
Glama
paifas

mcp-web-tools

by paifas
OverviewSchemaRelated ServersScoreDiscussions
TypeScript

mcp-web-tools

MCP server providing web search and content extraction tools for AI assistants. Works out of the box with zero config — no API keys, no Docker. Search and extract backends are decoupled and individually swappable between SearXNG (public or self-hosted), Tavily (hosted), and Firecrawl (keyless or self-hosted).

Install

No API keys, no Docker, no config files. Just add the server — it works out of the box using a public SearXNG instance for search and Firecrawl keyless for extraction.

Claude Code (CLI):

claude mcp add mcp-web-tools -- npx -y mcp-web-tools

Claude Desktop — add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):

{
  "mcpServers": {
    "mcp-web-tools": {
      "command": "npx",
      "args": ["-y", "mcp-web-tools"]
    }
  }
}

OpenCode — add to ~/.config/opencode/opencode.json (global) or .opencode.json in your project root:

"mcp-web-tools": {
  "type": "local",
  "command": ["npx", "-y", "mcp-web-tools"]
}

That's it — search and extraction both work with zero configuration. The sections below cover customizing the backends.

Related MCP server: CrewAI Web Search MCP

How it works

The server has two independent backends, each overridable via env vars in your client config:

  • Search (WEBTOOLS_SEARCH_PROVIDER): defaults to searxng — uses a public SearXNG instance. Override with tavily, or point SEARXNG_URL at your own instance.

  • Extract (WEBTOOLS_EXTRACT_PROVIDER): defaults to firecrawl keyless — no API key needed. Override with tavily, or set to none to disable web_read.

⚠️ The default public SearXNG instance is volunteer-operated. If it's down or rate-limited, set SEARXNG_URL to another instance or run your own.

Customizing backends

Use a different SearXNG instance

Point SEARXNG_URL at any SearXNG instance — public, self-hosted, or team-shared:

claude mcp add mcp-web-tools -e SEARXNG_URL=https://your-instance.example -- npx -y mcp-web-tools

Find public instances at searx.space.

Use Tavily instead (single key, both tools)

claude mcp add mcp-web-tools -e WEBTOOLS_SEARCH_PROVIDER=tavily -e TAVILY_API_KEY=your-key -- npx -y mcp-web-tools

Get a key at tavily.com. Extract automatically uses Tavily too (key reuse).

Firecrawl options

The default Firecrawl keyless tier gives ~1000 extractions/month. For higher limits:

claude mcp add mcp-web-tools -e FIRECRAWL_API_KEY=fc-your-key -- npx -y mcp-web-tools

Provider combinations

Search

Extract

Env vars

SearXNG (default)

Firecrawl keyless (default)

none

SearXNG

Firecrawl keyed

FIRECRAWL_API_KEY

SearXNG

Tavily

WEBTOOLS_EXTRACT_PROVIDER=tavily + TAVILY_API_KEY

SearXNG

none (web_read disabled)

WEBTOOLS_EXTRACT_PROVIDER=none

Tavily

Tavily

WEBTOOLS_SEARCH_PROVIDER=tavily + TAVILY_API_KEY

More claude mcp add one-liners:

# Point at your own SearXNG
claude mcp add mcp-web-tools -e SEARXNG_URL=http://localhost:8080 -- npx -y mcp-web-tools

# SearXNG search + Tavily extract
claude mcp add mcp-web-tools -e WEBTOOLS_EXTRACT_PROVIDER=tavily -e TAVILY_API_KEY=your-key -- npx -y mcp-web-tools

# Search only, web_read disabled
claude mcp add mcp-web-tools -e WEBTOOLS_EXTRACT_PROVIDER=none -- npx -y mcp-web-tools

# Firecrawl keyed (higher limits)
claude mcp add mcp-web-tools -e FIRECRAWL_API_KEY=fc-your-key -- npx -y mcp-web-tools

Self-hosting SearXNG (optional)

For full control over availability and rate limits, run your own SearXNG instance and point SEARXNG_URL at it.

The key requirement: SearXNG must have JSON output enabled. The default Docker image only serves HTML, so you need a settings.yml with json in search.formats. See the official docs:

→ SearXNG — Installation & Docker → SearXNG — settings.yml reference

Minimal settings.yml (mount this into the container):

use_default_settings: true
server:
  secret_key: "your-random-secret"
search:
  formats: [html, json]

Then point the server at it:

claude mcp add mcp-web-tools -e SEARXNG_URL=http://localhost:8080 -- npx -y mcp-web-tools

Full self-host (optional)

Run everything with no external network calls: SearXNG for search, Firecrawl for extract, both on your machine.

1. SearXNG — see Self-hosting SearXNG above.

2. Firecrawl — use Firecrawl's official self-host guide. Their stack needs Postgres, RabbitMQ, Redis, and Playwright:

→ firecrawl/firecrawl — SELF_HOST.md

3. Point mcp-web-tools at both:

claude mcp add mcp-web-tools -e SEARXNG_URL=http://localhost:8080 -e FIRECRAWL_URL=http://localhost:3002 -- npx -y mcp-web-tools

Tools

web_search

Search the web. Returns results with titles, URLs, and snippets. Backend is configured server-side (Tavily or SearXNG).

Parameters:

Parameter

Type

Default

Description

query

string

required

The search query

maxResults

number

5

Maximum number of results (1–20)

searchDepth

string

"basic"

"basic", "fast", "ultra-fast" (1 credit) or "advanced" (2 credits)

topic

string

"general"

"general", "news", or "finance"

timeRange

string

—

"day", "week", "month", or "year"

startDate

string

—

Start date filter (YYYY-MM-DD)

endDate

string

—

End date filter (YYYY-MM-DD)

includeDomains

string[]

—

Only include results from these domains

excludeDomains

string[]

—

Exclude results from these domains

includeAnswer

boolean

true

Include an AI-generated answer summary

web_read

Extract clean content from web pages. Returns page text stripped of navigation, ads, and scripts. Supports up to 20 URLs per request. Backend is configured server-side (Tavily or Firecrawl). Not registered when WEBTOOLS_EXTRACT_PROVIDER=none.

Parameters:

Parameter

Type

Default

Description

urls

string[]

required

URLs to extract content from (1–20). Must be http:// or https://

extractDepth

string

—

"basic" (1 credit per 5 URLs, raw page HTML as markdown including navigation/boilerplate) or "advanced" (2 credits per 5 URLs, clean article content with nav/ads/sidebar/footer stripped)

includeImages

boolean

false

Include extracted image URLs

credit_balance

Check your provider credit balance and usage. Returns "not supported" when the active provider has no credit system (e.g. SearXNG).

GitHub Tools

Three tools for reading public GitHub repository content directly via the GitHub REST API. These do not go through the search provider — they live in their own namespace and work anonymously.

github_get_repo_structure

List the directory structure of a GitHub repository path (single level, non-recursive). Useful for understanding project layout.

Parameters:

Parameter

Type

Default

Description

repo

string

required

Repository in the form owner/repo (e.g. vitejs/vite)

path

string

/

Directory path inside the repo

ref

string

default branch

Git ref (branch, tag, or commit SHA)

github_read_file

Read the full content of a file in a GitHub repository. Files larger than 512 KB or detected as binary are rejected.

Parameters:

Parameter

Type

Default

Description

repo

string

required

Repository in the form owner/repo

path

string

required

Path to the file inside the repo

ref

string

default branch

Git ref (branch, tag, or commit SHA)

github_search_repo

Search a GitHub repository across code, issues, and pull requests in one call. When kind=all (the default), all three searches run in parallel and results are grouped by type. Code search uses GitHub's /search/code endpoint, which requires a GITHUB_TOKEN (anonymous code search is not supported by GitHub — the call returns 401 without a token). Issues and PRs use /search/issues and work anonymously.

Parameters:

Parameter

Type

Default

Description

repo

string

required

Repository in the form owner/repo

query

string

required

Search query. GitHub search syntax is supported (e.g. "auth token", "bug in login", "label:bug")

kind

string

"all"

"code", "issues", "prs", or "all" (fans out across all three in parallel)

state

string

"all"

Filter for issues/PRs only ("open", "closed", or "all"). Ignored for code

maxResults

number

5

Max results per kind (1–10). When kind=all, the tool returns up to 3× this number of results

Environment Variables

Variable

Required

Default

Description

WEBTOOLS_SEARCH_PROVIDER

No

searxng

Search backend: tavily or searxng

SEARXNG_URL

No

https://search.mdosch.de

Base URL of a SearXNG instance. Defaults to a public instance; set to your own for reliability

TAVILY_API_KEY

Conditional

—

Tavily API key. Required when search or extract provider is tavily. Get one at tavily.com

WEBTOOLS_EXTRACT_PROVIDER

No

derived*

Extract backend: tavily, firecrawl, or none. When unset: tavily if search is tavily, otherwise firecrawl

FIRECRAWL_URL

No

https://api.firecrawl.dev

Base URL of a Firecrawl instance. Accepts any HTTP(S) URL (local, hosted, or self-hosted)

FIRECRAWL_API_KEY

No

—

Optional. Omit for keyless mode (~1000 credits/month, IP-bucketed). Set for higher hosted limits. Ignored on self-hosted bypass mode

GITHUB_TOKEN

No

—

Optional GitHub token for the github_* tools. Lifts rate limits from 60 to 5000 requests/hour. Create one at github.com/settings/tokens (no scopes needed for public repos)

WEBTOOLS_MAX_RESULTS

No

5

Default number of results (must be 1–20)

WEBTOOLS_SEARCH_DEPTH

No

basic

Default search depth

WEBTOOLS_CACHE_TTL

No

3600

Cache TTL in seconds (0 disables)

WEBTOOLS_CACHE_MAX_ENTRIES

No

100

Maximum cache entries before LRU eviction (0 disables caching)

WEBTOOLS_CACHE_SWEEP_INTERVAL_MS

No

300000

Interval in ms to sweep expired entries (0 disables periodic sweep)

WEBTOOLS_DEBUG

No

—

Set to any value to enable debug logging to stderr

* WEBTOOLS_EXTRACT_PROVIDER defaults to tavily when WEBTOOLS_SEARCH_PROVIDER=tavily, and to firecrawl otherwise.

Provider limitations

Each backend supports a different subset of features. Unsupported params are silently ignored.

Feature

Tavily

SearXNG

Firecrawl

web_search

✅

✅

— (extract only)

web_read / extract

✅

— (search only)

✅

AI answer (includeAnswer)

✅

❌ ignored

—

Native domain filter

✅

post-filtered (may return fewer than maxResults)

—

topic=finance

✅

maps to general

—

searchDepth

✅

❌ ignored

—

extractDepth=advanced

✅

—

✅ (maps to onlyMainContent)

includeImages

✅

—

❌ ignored

Credit/usage (credit_balance)

✅

❌ "not supported"

❌ "not supported"

Common pitfalls:

  • SearXNG 403 — JSON output is disabled on the instance. Edit settings.yml (search.formats must include json) and restart. The docker run snippet in Backends bakes this in via the mounted settings file.

  • SearXNG 429 — rate limiter is on. Disable server.limiter in settings.yml, or use a different instance.

  • Firecrawl 429 — keyless free tier exhausted (~1000 credits/month, 10/min). Set FIRECRAWL_API_KEY for higher limits, or self-host.

Example Output

Node.js 22 introduces require() support for ES modules, a WebSocket client, and updates to the V8 JavaScript engine.

### 1. [Node.js — Node.js 22 is now available!](https://nodejs.org/blog/announcements/v22-release-announce)
> We're excited to announce the release of Node.js 22! Highlights include require()ing ES modules, a WebSocket client, updates of the V8 JavaScript engine, and more!

*Response time: 1.2s*

---

Sources:
- [Node.js — Node.js 22 is now available!](https://nodejs.org/blog/announcements/v22-release-announce)

Security note

This server is designed for trusted AI clients (Claude Code, Claude Desktop, OpenCode). The web_read tool accepts any http(s):// URL supplied by the calling client and does not implement SSRF protections (e.g. blocking of private/internal IP ranges). Do not expose this server to untrusted input.

License

MIT

Available Tools

6 tools
credit_balanceA

Check your provider API credit balance and usage.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.7/5.0
Behavior2/5

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

No annotations are provided, and the description does not disclose behavioral traits such as whether the operation is read-only, requires authentication, or what side effects exist. It only states the purpose, leaving the agent uninformed about important safety or permission aspects.

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, clear sentence with no unnecessary words. It is front-loaded with the action and resource, and every word earns its place.

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 no output schema and no annotations, the description is minimal. For a simple read operation, it might be sufficient, but it lacks details about the return format or any usage constraints, making it only partially complete.

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 input schema has no parameters (schema description coverage 100%), so the description adds meaning beyond the schema by naming the resource ('credit balance and usage'). Baseline for zero parameters is 4.

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 tool is named 'credit_balance' and the description states 'Check your provider API credit balance and usage.' This specifies a clear verb ('Check') and resource ('provider API credit balance and usage'), distinguishing it from siblings like web_search or github_get_repo_structure which handle different domains.

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

Usage Guidelines3/5

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

The description provides no explicit guidance on when to use or not use this tool, nor does it mention alternatives. However, given the distinct purpose (credit balance) and sibling tools (web and GitHub operations), the usage context is implied but not stated.

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

github_get_repo_structureA

List the directory structure of a GitHub repository path (single level, non-recursive). Useful for understanding project layout and discovering files. Works without a token (anonymous rate limits apply — set GITHUB_TOKEN for higher limits).

ParametersJSON Schema
NameRequiredDescriptionDefault
refNoGit ref (branch name, tag, or commit SHA). Defaults to the repo's default branch.
pathNoDirectory path inside the repo. Defaults to the root. Use forward slashes.
repoYesGitHub repository in the form 'owner/repo'

TDQS

A4.4/5.0
Behavior4/5

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

No annotations provided, so description carries full burden. It discloses non-recursive behavior, anonymous rate limits, and token usage for higher limits, which are key behavioral traits.

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, front-loaded with primary action, no redundant words. Every sentence adds value.

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?

No output schema, but description indirectly implies output (list of items). For a simple directory listing, this is mostly complete; could mention return format but not necessary given low complexity.

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 coverage is 100% with descriptions. Description adds value beyond schema by explaining defaults for ref (default branch) and path (root), and guidance on forward slashes.

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 uses specific verb 'List' and resource 'directory structure', and clarifies 'single level, non-recursive', distinguishing it from recursive alternatives and sibling tools like github_read_file.

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?

Provides context on when to use ('understanding project layout') and mentions token requirements, but does not explicitly exclude scenarios or name sibling tools.

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

github_read_fileA

Read the full content of a file in a GitHub repository. Returns the decoded text. Files larger than 512 KB or detected as binary are rejected. Works without a token (anonymous rate limits apply — set GITHUB_TOKEN for higher limits).

ParametersJSON Schema
NameRequiredDescriptionDefault
refNoGit ref (branch name, tag, or commit SHA). Defaults to the repo's default branch.
pathYesPath to the file inside the repo (forward slashes).
repoYesGitHub repository in the form 'owner/repo'

TDQS

A4.3/5.0
Behavior4/5

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

Discloses file size limit (512 KB) and binary rejection, plus tokenless operation. No annotation provided, so description bears full burden; it covers key constraints.

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?

Three concise sentences: purpose, limitations, token info. No wasted words, front-loaded with key action.

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?

Covers input, behavior, and return value clearly. No output schema needed; 'returns decoded text' is sufficient. Addresses constraints adequately.

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?

Schema covers all parameters with descriptions (100% coverage). Description adds no extra param details; baseline 3 is appropriate.

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?

Clearly states verb 'Read', resource 'file in a GitHub repository', and mentions 'Returns the decoded text'. Distinct from sibling tools like github_get_repo_structure (directory) and github_search_repo.

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?

Provides context on token usage and anonymous rate limits. Implicitly clear when to use (to read file content). No explicit exclusions or alternatives, but purpose is unambiguous.

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

github_search_repoA

Search a GitHub repository across code, issues, and pull requests in one call. Code search uses /search/code (requires the repo to be indexed by GitHub). Issues and PRs use /search/issues. Works without a token (anonymous rate limits apply — set GITHUB_TOKEN for higher limits).

ParametersJSON Schema
NameRequiredDescriptionDefault
kindNoWhat to search. 'all' fans out across code, issues, and PRs in parallel. Default 'all'.
repoYesGitHub repository in the form 'owner/repo'
queryYesSearch query. GitHub search syntax is supported (e.g. 'auth token', 'bug in login', 'TODO refactor', 'label:bug').
stateNoFilter for issues/PRs only. Ignored for code. Default 'all'.
maxResultsNoMax results per kind. Default 5 (so 'all' returns up to 15 total).

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden. It discloses that code search requires indexing, that anonymous rate limits apply, and that 'all' fans out in parallel. It does not detail side effects or error handling, but the disclosed behaviors are sufficient for safe invocation.

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 three sentences, concise and front-loaded: the first sentence states the primary purpose. Every sentence adds essential information without redundancy, making it highly efficient.

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 has 5 parameters, 2 required, no output schema, and multiple search types, the description covers usage, constraints, and behavior adequately. It could note return format, but completeness is high for the complexity level.

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 coverage is 100% with descriptions for all parameters. The description adds value by explaining that 'all' fans out in parallel, that state is ignored for code, and default maxResults values. This enhances understanding beyond the schema alone.

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 searches a GitHub repository across code, issues, and pull requests in one call, specifying the underlying API endpoints. It differentiates from sibling tools like github_get_repo_structure (structure) and github_read_file (reading files), making the purpose unambiguous.

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 provides context on authentication (anonymous vs. token) and a prerequisite for code search (repo must be indexed). It implies usage for searching across repo content but does not explicitly state when not to use it or compare with alternatives, missing a small bit of guidance.

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

web_readA

Extract clean content from web pages. Returns page text stripped of navigation, ads, and scripts. Supports up to 20 URLs per request.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlsYesURLs to extract content from (1-20)
extractDepthNoExtraction depth: basic (1 credit per 5 URLs, returns raw page HTML as markdown including navigation and boilerplate) or advanced (2 credits per 5 URLs, extracts clean article content with navigation/ads/sidebar/footer stripped)
includeImagesNoInclude extracted image URLs (default: false)

TDQS

A3.5/5.0
Behavior2/5

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

No annotations are provided, so the description carries full burden for behavioral disclosure. It mentions 'clean content' and 'up to 20 URLs', but fails to disclose credit costs (only hinted in parameter descriptions), rate limits, authentication requirements, side effects, or error handling. This is a significant gap for a web scraping 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 extremely concise at two sentences, with no wasted words. It front-loads the core purpose and then adds a key output characteristic and a constraint. Every sentence earns its place.

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 complexity (3 parameters, no output schema, no annotations), the description is adequate but leaves gaps. It does not explain credit costs, the difference between basic/advanced extraction beyond schema, or return value format. Important behavioral aspects are missing, making it incomplete for an agent to use optimally.

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?

Schema coverage is 100%, so the baseline is 3. The description adds high-level context about the tool's output, but does not significantly enhance the parameter meanings beyond what the schema already provides. The schema descriptions for extractDepth and includeImages are detailed, so the description adds little extra value.

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: 'Extract clean content from web pages.' It specifies the verb 'extract' and the resource 'content from web pages', and distinguishes itself from siblings like web_search by focusing on extracting content from given URLs rather than searching.

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

Usage Guidelines3/5

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

The description implies usage for extracting content from specific URLs, but it does not explicitly state when to use this tool versus alternatives like web_search. It lacks explicit 'when-not-to-use' guidance or mention of prerequisites, though the context of sibling tools provides some implicit differentiation.

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

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: credit balance, web search, web reading, GitHub repo structure, file reading, and search. No overlaps exist.

Naming Consistency4/5

GitHub tools consistently use 'github_' prefix with verb_noun pattern. Web tools use 'web_' prefix. However, 'credit_balance' does not follow this pattern, introducing a minor inconsistency.

Tool Count5/5

Six tools is well-scoped for the server's purpose, covering both web and GitHub read operations without being overwhelming or too sparse.

Completeness4/5

The set covers essential read operations for web and GitHub, but lacks write capabilities and more advanced web tools (e.g., scraping). Minor gaps exist but core functionality is present.

Maintenance

ActivityStale
ResponsivenessSyncing

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

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/paifas/mcp-web-tools'

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