browser-buddy
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
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| read_active_tabA | Read the user's currently active Chrome tab through their real, logged-in browser profile. Returns the page URL, title, and cleaned readable text. Use when WebFetch/fetch is blocked by a 403, login wall, or bot detection. |
| open_and_read_urlA | Open a URL in a background Chrome tab using the user's real browser profile (cookies and login sessions included), extract its readable text, then close the tab. For pages behind logins, paywalls-with-session, or bot checks that defeat server-side fetchers. |
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 overlapping 'read page content' semantics, but their triggers are clearly differentiated: read_active_tab targets the current tab, while open_and_read_url takes a URL and manages its own tab lifecycle. Descriptions make the boundary explicit (active vs. newly opened), so misselection is unlikely.
Both names use snake_case verb-first phrasing (read_active_tab, open_and_read_url). The slight asymmetry ('read_' vs 'open_and_read_') is a minor deviation but still readable and predictable.
Two tools is thin for a browser-based retrieval server, even with a narrow scope. It is not egregious, but typical browser surfaces (list tabs, interact, screenshot) suggest more could reasonably earn a place.
The core use case — reading pages that defeat server-side fetchers — is covered by reading the active tab or an arbitrary URL. However, there is no interaction, tab listing, screenshot, or explicit JS-wait capability, leaving notable gaps for a browser-profile-based tool.