MCP Browser Agent
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 |
|---|---|
| get_planner_stateA | Get the current browser state and planning context. This tool must be executed before execute_actions tool. |
| execute_actionsB | Execute actions from the planner state. |
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: get_planner_state retrieves browser state and planning context, while execute_actions performs actions based on that state. There is no overlap or ambiguity between these functions.
Both tools follow a consistent verb_noun pattern with clear action-oriented names (get_planner_state, execute_actions). The naming convention is uniform and predictable throughout the set.
With only 2 tools for a browser automation server, the surface feels severely limited. While the tools cover a basic planning-execution loop, typical browser automation requires more granular operations like navigation, element interaction, or content extraction.
The toolset provides only a high-level planning/execution abstraction without direct browser manipulation capabilities. There are significant gaps for common browser tasks like navigating to URLs, clicking elements, extracting text, or handling dialogs, which agents would need for robust automation.