Skip to main content
Glama
ashley-ha

MCP Browser Agent

by ashley-ha

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

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

NameDescription
get_planner_stateA

Get the current browser state and planning context. This tool must be executed before execute_actions tool.

Must return a JSON string in the format:
{
    "current_state": {
        "evaluation_previous_goal": "Success|Failed|Unknown - Analysis of previous actions",
        "memory": "Description of what has been done and what to remember",
        "next_goal": "What needs to be done with the next immediate action"
    },
    "action": [
        {"action_name": {"param1": "value1", ...}},
        ...
    ]
}
execute_actionsB

Execute actions from the planner state.

Args:
    actions: A dictionary containing the planner state and actions in format:
            {
                "current_state": {
                    "evaluation_previous_goal": str,
                    "memory": str,
                    "next_goal": str
                },
                "action": [
                    {"action_name": {"param1": "value1"}},
                    ...
                ]
            }
            
Note: If the page state changes (new elements appear) during action execution,
the sequence will be interrupted and you'll need to get a new planner state.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

B3.4/5.0

Scored across 2 tools

Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count2/5

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.

Completeness2/5

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.

Maintenance

ActivityInactive
ResponsivenessNo issues