Browser Use
Lets AI do web tasks for you, such as filling forms, searching and extracting data, in the maker’s cloud browsers or on your computer.
Description from the maker (original English)
Load testing and synthetic monitoring platform: test with Playwright, Browser Bot, or Protocol Bots.
These three are never merged into one score: opinions, measurements and popularity are different things.
We have not written a plain-language summary for this one yet. Below are the facts we read from the registry.
Pick the AI app you use, then copy the settings.
You need
Which app do you use?
Pick your app above. We remember it, so next time the button says “Install in …”.
Works in Claude on the web, desktop and mobile:
https://api.loadster.com/mcpRun this in your terminal
claude mcp add --transport http loadster https://api.loadster.com/mcpPaste into .cursor/mcp.json in your project, or ~/.cursor/mcp.json
{
"mcpServers": {
"loadster": {
"url": "https://api.loadster.com/mcp"
}
}
}Your browser asks to open the app, then the app shows the settings and asks you to confirm. Key values are left empty for you to fill in.
Paste into .vscode/mcp.json in your project
{
"servers": {
"loadster": {
"type": "http",
"url": "https://api.loadster.com/mcp"
}
}
}Your browser asks to open the app, then the app shows the settings and asks you to confirm. Key values are left empty for you to fill in.
ChatGPT connects only to servers on the internet:
https://api.loadster.com/mcpMenu names can differ slightly by plan and over time.
Your choice stays on this device in a cookie; no account needed.
These settings are generated from the maker’s registry entry. If the README says otherwise, follow the README.
We have not read this server’s tool list yet; we check endpoints in rotation.
We check information anyone can see; we have not read the code. Checks that do not apply are left out of the count. · Checked Nov 6, 2026
The registry name was verified against the domain loadster.com (the registry checks domain ownership)
We have not read this repo from GitHub yet
We have not read this repo from GitHub yet
Not checked yet; we check endpoints in rotation
Not checked yet; we check endpoints in rotation
Not checked yet; we read the tool list when we check the endpoint
Compared with every active server in this category in the registry. Stars count only when the publisher owns the repo.
It passed 1 of 1 applicable basic checks. We have not read the code. Before adding a key or token, see what access the server asks for and use a key with only the permissions you need.
The registry does not list a required key, though some servers ask you to sign in on first use.
It runs in the maker’s cloud. Connect over the internet with nothing to install, but what you send passes through the maker’s servers.
The GitHub repo last changed –, and the latest version (2.0.1) reached the registry 6 days ago.
Apps that support MCP, such as Claude Desktop, Claude Code, Cursor and VS Code. It connects by URL, so apps that accept remote MCP servers work too, such as ChatGPT in developer mode.
In the same category: Browser Use, Chrome DevTools MCP, MCP Server Browser
Servers in the same category from other makers, sorted by stars.
Reading a card:★ GitHub starsiThree pillars: reviews · checks · usageiUpdated = latest version published to the registryi
Lets AI do web tasks for you, such as filling forms, searching and extracting data, in the maker’s cloud browsers or on your computer.
Lets AI use Chrome’s developer tools to inspect pages, find what makes them slow and spot errors. Made by the Chrome DevTools team.
MCP server for browser use access
Copied from the maker’s repo as written. PopNx MCP has not reviewed or endorsed it. HTML, images and scripts are removed. Links lead off this site.
Loadster is a cloud load testing and monitoring platform. Its built-in Model Context Protocol (MCP) server lets AI agents like Claude, ChatGPT, Codex, Cursor, and VS Code write and play load test scripts, build load test scenarios, set up monitors, and analyze results in your Loadster account.
This repository is the public home for connecting to that server: setup snippets for each client, the Claude Code plugin, and the metadata behind Loadster's listings in MCP directories. The server itself is hosted by Loadster at https://api.loadster.com/mcp, and its source is not published here. Loadster is also an official plugin in the ChatGPT and Codex plugin directory.
The maintained, full-length guide is the AI Assistants & MCP chapter of the Loadster manual. This README is the short version.
| URL | https://api.loadster.com/mcp |
| Transport | Streamable HTTP |
| Authentication | OAuth 2.1 (preferred), or a personal access token in an Authorization: Bearer header |
| Registry name | com.loadster/loadster-mcp |
OAuth is the easiest way to connect. Clients that support MCP OAuth send you to Loadster to approve the connection in your browser, and you can review or revoke connected agents on the API & MCP page in your Loadster settings. The approval page leads with the web address Loadster can verify for the app, so check that it's one you expect before you approve. You also choose an access level there: Read (selected to start with), Read+Write, or Read+Write+Execute. To change it later, revoke the connection and connect again. Changing or resetting your Loadster password disconnects every OAuth-connected agent, so reconnect each one afterward. Personal access tokens keep working.
Personal access tokens are for clients that can't do OAuth, and for CI jobs and scripted agents. The same kind of token also works for calling the Loadster REST API directly. Create one in the Loadster dashboard under Settings → API & MCP → Personal Access Tokens, choose its access level, copy it right away (it's only shown once), and send it as Authorization: Bearer YOUR_TOKEN. A token acts as you within the team where you created it, so treat it like a password.
The quickest way is the plugin from this repository, which adds the Loadster MCP server plus skills for a sensible load testing workflow: setup to connect, setup-script for a first script, setup-scenario for a first load test scenario, setup-monitor for a first synthetic monitor, load-test for a full test, and results for reading what happened.
/plugin marketplace add loadster/loadster-mcp
/plugin install loadster@loadster
Then run /mcp, pick loadster, and approve the OAuth connection in your browser. Ask Claude something like _"List my Loadster projects"_ to confirm it can reach your account.
Without the plugin, add the server directly and Claude Code will walk you through OAuth:
claude mcp add --transport http loadster https://api.loadster.com/mcp
Or with a personal access token, for headless use:
claude mcp add --transport http loadster https://api.loadster.com/mcp --header "Authorization: Bearer YOUR_TOKEN"
The equivalent project-level .mcp.json:
{
"mcpServers": { "loadster": { "type": "http", "url": "https://api.loadster.com/mcp" } } }
Claude Desktop and claude.ai connect to remote MCP servers as custom connectors, which use OAuth.
https://api.loadster.com/mcp.Loadster is an official plugin in the ChatGPT and Codex plugin directory, with the setup, load-test, and results skills. The new setup-script, setup-scenario, and setup-monitor skills reach it when the directory listing is updated.
/plugins in the Codex CLI, then start a new session.The Codex IDE extension doesn't support plugins, so it connects through Codex's MCP configuration, which the desktop app and CLI share:
codex mcp add loadster --url https://api.loadster.com/mcp
codex mcp login loadster
Or with a personal access token in ~/.codex/config.toml:
[mcp_servers.loadster]
url = "https://api.loadster.com/mcp" bearer_token_env_var = "LOADSTER_MCP_TOKEN"
If the plugin isn't available on your ChatGPT account, you can still add Loadster as a custom connection in Developer mode (Settings → Security and login). Open Plugins, add a connection with the URL https://api.loadster.com/mcp, then add it to a new conversation from the tools menu and approve the OAuth connection.
Or add it to .cursor/mcp.json in your project (or ~/.cursor/mcp.json for all projects) and approve the OAuth connection when Cursor first connects:
{
"mcpServers": { "loadster": { "url": "https://api.loadster.com/mcp" } } }
To use a personal access token instead, add "headers": { "Authorization": "Bearer ${env:LOADSTER_MCP_TOKEN}" } and set LOADSTER_MCP_TOKEN in the environment before starting Cursor.
Or run MCP: Add Server from the Command Palette, or add it to .vscode/mcp.json:
{
"servers": { "loadster": { "type": "http", "url": "https://api.loadster.com/mcp" } } }
To use a personal access token, declare a promptString input with "password": true and reference it in an Authorization header. The manual has the complete example.
Any client that supports remote servers over Streamable HTTP can connect the same way. For clients that only support local (stdio) servers, the mcp-remote bridge usually works. Leave out the --header arguments to have it run the OAuth flow instead of using a token:
{
"mcpServers": { "loadster": { "command": "npx", "args": ["-y", "mcp-remote", "https://api.loadster.com/mcp", "--header", "Authorization: Bearer YOUR_TOKEN"] } } }
The server exposes most of the Loadster dashboard. Clients fetch the live tool list when they connect, so this table is a map of the surface rather than the source of truth. The MCP tool reference in the Loadster manual is generated from the tool definitions themselves, with each tool's parameters and whether it is a Read, Write, Sensitive Write, or Execute tool.
| Group | Tools |
|---|---|
| Projects and documentation | list_projects, create_project, get_documentation, get_scripting_api, get_example, list_command_types, get_command_schema, get_variable_schema |
| Scripts | list_scripts, get_script, create_script, update_script, duplicate_script, delete_script, import_script, validate_script, play_script, get_play_status, stop_script, get_step_detail, get_screenshot, list_script_revisions, get_script_revision, restore_script_revision, list_script_assets, get_script_asset, put_script_asset, delete_script_asset |
| Datasets | list_datasets, get_dataset, create_dataset, update_dataset, append_dataset_rows, delete_dataset |
| Scenarios and engines | list_scenarios, get_scenario, create_scenario, update_scenario, delete_scenario, list_engines |
| Load tests and reports | launch_load_test, stop_load_test, get_load_test_status, list_load_tests, get_load_test_report, get_load_test_url_timings, update_load_test_notes |
| Monitoring | list_monitoring_locations, list_monitors, get_monitor, create_monitor, update_monitor, enable_monitor, disable_monitor, delete_monitor, list_monitor_cycles, get_monitor_cycle_detail, get_monitoring_summary, list_incidents, get_incident |
| Feedback | submit_feedback |
Scripts, scenarios, datasets, and monitors can carry tags. The list tools report each item's tag names, and the create and update tools take a tags list. Tags are shared across your team, so agents reuse the names you already have and create a new tag only when you ask for one.
Updating a script, scenario, monitor, or dataset changes only the fields the agent sends and keeps the rest. A list that's sent, such as a scenario's bot groups or a dataset's rows, replaces the stored list rather than merging into it. The load test tools take loadTestId and scenario bot groups take engineId; the older names testId and loadEngineId still work in 2.0 and will be removed in the next major version.
The tools an agent sees depend on the access level you grant. Read sees the tools that read, Read+Write adds the tools that create, change, delete, and play scripts, and Read+Write+Execute adds launch_load_test, stop_load_test, and enable_monitor. Launching a load test and enabling a monitor send real traffic and burn Fuel unless your plan covers them, so the server tells the agent to get your go-ahead before either. Before a launch the agent gives you your balance and, when the test would burn Fuel, the Fuel estimate range the dashboard shows. A launch with no estimate runs on your plan and burns no Fuel, and one with an estimate runs entirely on Fuel. If your plan can't run a test right now, the agent's launch is refused and you can launch it on Fuel from the dashboard. Monitors are covered by a plan that includes monitoring up to its limits, and use Fuel beyond them. At the other two levels the agent gets everything ready and hands off so you push the launch button in the dashboard.
Some actions are always left to humans. An agent cannot manage notification policies or maintenance windows, or administer your team, billing, or Fuel.
Every tool carries MCP annotations (readOnlyHint, destructiveHint, idempotentHint, openWorldHint), so clients that honor them can prompt before writes and deletes.
Only the beginning is shown; read the rest in the repo