@webuplink/mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PORT | No | Local HTTP transport port | 3001 |
| MCP_HTTP_HOST | No | Local HTTP transport bind address | 127.0.0.1 |
| WEBUPLINK_API_KEY | Yes | Your WebUplink API key | |
| WEBUPLINK_BASE_URL | No | API base URL | https://api.webuplink.ai |
| MCP_HTTP_ALLOWED_HOSTS | No | Comma-separated Host/Origin names accepted by the HTTP boundary | localhost,127.0.0.1 |
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": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| browseB | Browse a web page or execute tools on a page. Use url to open a new session, or session_id to continue an existing session. |
| close_sessionA | Close a browser session to free resources. Sessions auto-expire after 5 minutes of inactivity, but explicit cleanup is recommended. |
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 2 tools
The two tools have completely distinct purposes: browse handles opening or continuing a session and interacting with pages, while close_session explicitly handles teardown and resource cleanup. There is no overlap between them, so an agent should not confuse which tool to call.
Both tool names use imperative verbs, which is coherent, but browse is a bare verb while close_session follows a verb_noun pattern. The inconsistency is minor given the very small tool set, but a more consistent name like browse_page would improve the pattern.
At two tools, the server feels thin for what appears to be a web browsing or browser automation domain. The two tools do form a minimal session lifecycle, so the count is borderline rather than obviously wrong, but it likely underrepresents the full range of browsing actions an agent might need.
The core lifecycle of opening/continuing a session with browse and closing it with close_session is covered, but there is no explicit session listing or status tool, and the browse tool appears to absorb many possible page actions into one generic entry point. Agents may be able to work around the gaps, but the surface is notably sparse for the stated purpose.