Fetch Browser
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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
Server capabilities have not been inspected yet.
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| fetch_urlC | Fetch content from a URL with proper error handling and response processing |
| google_searchC | Execute a Google search and return results in various formats |
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 clearly distinct purposes: fetch_url retrieves content from a specific URL, while google_search performs web searches and returns results. There is no overlap in functionality, making it easy for an agent to choose the correct tool based on the task.
Both tools follow a verb_noun pattern (fetch_url, google_search), which is consistent and predictable. The minor deviation is that google_search includes a brand name, but this does not break the overall naming convention.
With only 2 tools, the server feels thin for a browser-related purpose, as it lacks common operations like navigating pages, handling cookies, or interacting with web elements. However, the tools provided are core functionalities, so it's borderline appropriate.
For a browser server, there are significant gaps in coverage, such as no tools for page navigation, form submission, JavaScript execution, or session management. The surface is severely incomplete for typical browser automation tasks, limiting agent effectiveness.