mcp-web
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MCPWEB_TIMEOUT | No | Per-request timeout, in seconds. | 20 |
| MCPWEB_ALLOWLIST | No | Comma-separated hosts; when set, nothing else is reachable. | |
| MCPWEB_MAX_BYTES | No | Response body cap in bytes. | 2000000 |
| MCPWEB_USER_AGENT | No | User agent string sent on every request. | Chrome-ish |
| MCPWEB_ALLOW_PRIVATE | No | Set to 1 to let the model reach localhost and your LAN. | 0 |
| MCPWEB_MAX_REDIRECTS | No | Redirect hop limit. | 5 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| web_searchA | Search the web with DuckDuckGo. Returns a list of results with title, url and snippet. Follow up with fetch_url on any result whose full text you need. |
| fetch_urlA | Fetch a web page and return its main content as markdown. Use this for ordinary pages and articles. If the result looks empty or is obviously a JavaScript shell, retry with render_page. |
| http_requestA | Make an arbitrary HTTP request and return the raw response. Use this for JSON APIs. For reading web pages prefer fetch_url, which strips navigation and boilerplate. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
Each tool has a clearly distinct role: web_search finds pages, fetch_url converts pages to markdown, and http_request handles raw API calls. The descriptions also explicitly steer agents toward the right tool, so confusion is unlikely.
web_search and fetch_url follow a clean verb_noun pattern, while http_request is a noun phrase and breaks the pattern. Overall the names are still simple, lowercase, and readable, with only one minor deviation.
Three tools is a reasonable, well-scoped size for a focused web access server. Each tool earns its place and there is no obvious redundancy.
The basic search/fetch/request workflow is covered, but fetch_url explicitly tells agents to retry with render_page for JavaScript-heavy pages while render_page does not exist in the tool set. This creates a notable dead end for those pages and makes the surface feel incomplete.