Browser Use
Browser agents and stealth cloud browsers for AI: run web tasks, fill forms, extract data.
作者提供的说明(英文原文)
Load testing and synthetic monitoring platform: test with Playwright, Browser Bot, or Protocol Bots.
这三项永远不会合并成一个分数:意见、测量和人气是不同的东西。
我们还没有为它写通俗的介绍。下面是我们从注册中心读取到的事实。
选择你使用的 AI 应用,然后复制设置。
你需要
你用的是哪个应用?
在上方选择你的应用。我们会记住它,下次按钮会显示“安装到 …”。
适用于网页版、桌面版和手机版 Claude:
https://api.loadster.com/mcp在终端中运行这条命令
claude mcp add --transport http loadster https://api.loadster.com/mcp粘贴到项目中的 .cursor/mcp.json,或 ~/.cursor/mcp.json
{
"mcpServers": {
"loadster": {
"url": "https://api.loadster.com/mcp"
}
}
}浏览器会先询问是否打开应用,然后应用会显示设置并请你确认。密钥的值会留空,由你自己填写。
粘贴到项目中的 .vscode/mcp.json
{
"servers": {
"loadster": {
"type": "http",
"url": "https://api.loadster.com/mcp"
}
}
}浏览器会先询问是否打开应用,然后应用会显示设置并请你确认。密钥的值会留空,由你自己填写。
ChatGPT 只能连接互联网上的服务器:
https://api.loadster.com/mcp菜单名称可能因套餐和版本不同而略有差异。
你的选择通过 Cookie 保存在这台设备上,无需账户。
这些设置是根据作者在注册中心的条目生成的。如果 README 的写法不同,请以 README 为准。
我们还没有读取这个服务器的工具列表;我们会轮流检查各个端点。
我们检查的是任何人都能看到的信息;我们没有阅读代码。不适用的检查项不计入总数。 · 检查于 2026年11月6日
注册名称已通过域名 loadster.com 验证(注册中心会核实域名所有权)
我们还没有从 GitHub 读取这个仓库
我们还没有从 GitHub 读取这个仓库
尚未检查;我们会轮流检查各个端点
尚未检查;我们会轮流检查各个端点
尚未检查;我们会在检查端点时读取工具列表
与注册中心里这个分类中所有活跃的服务器比较。只有当发布者拥有该仓库时,星标数才计入。
它在 1 项适用的基础检查中通过了 1 项。我们没有阅读代码。在添加密钥或令牌之前,请先看看这个服务器要求哪些权限,并使用只具备所需权限的密钥。
注册中心没有列出必需的密钥,不过有些服务器会在首次使用时要求你登录。
它在作者的云端运行。通过互联网连接,无需安装,但你发送的内容会经过作者的服务器。
GitHub 仓库最后更新于–,最新版本(2.0.1)于6天前进入注册中心。
支持 MCP 的应用,例如 Claude Desktop、Claude Code、Cursor 和 VS Code。它通过 URL 连接,所以接受远程 MCP 服务器的应用也可以使用,例如开启开发者模式的 ChatGPT。
同一分类中有:Browser Use, Chrome DevTools MCP, MCP Server Browser
同一分类中其他作者的服务器,按星标数排序。
如何看卡片:★ GitHub 星标i三大支柱:评价 · 检查 · 使用情况i更新 = 最新版本发布到注册中心的时间i
Browser agents and stealth cloud browsers for AI: run web tasks, fill forms, extract data.
MCP server for Chrome DevTools
MCP server for browser use access
按原文从作者的仓库复制。PopNx MCP 没有审查或背书其内容。HTML、图片和脚本已被移除。链接会离开本站。
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.
只显示了开头部分;其余内容请在仓库中阅读