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.
Computer or cloud✓ browser-use.com
Ghost Inspector MCP
Overview
Description from the maker (original English)
Analyze, validate and safely update Ghost Inspector end-to-end browser tests
PopNx MCP’s three pillars
These three are never merged into one score: opinions, measurements and popularity are different things.
- User voiceiNo reviews yetReviews open together with accounts in a later step
- Our basic checksi1 of 1 passedChecked from public information; code not scanned yet
- UsageiVery new↓ 71/wk · ★ –
What you can do with it
We have not written a plain-language summary for this one yet. Below are the facts we read from the registry.
- Connection: Runs on your computer
- Transport: stdio
- Category: Web & browsers
- You need to fill in: GHOST_INSPECTOR_API_KEY
Install
Pick the AI app you use, then copy the settings.
Before you install
- Basic checks: 1 of 1 passed
- Runs on your computer with your user’s permissions (files, network, apps).
- You fill in yourself:
GHOST_INSPECTOR_API_KEY,GHOST_INSPECTOR_ORG_ID,GHOST_INSPECTOR_ALLOW_WRITES,GHOST_INSPECTOR_ALLOW_RUNS,GHOST_INSPECTOR_BACKUP_DIR
Values marked secret are keys to your account. Never share them or paste them into a chat.
You need
- npmNode.js installed (for the npx command)
Which app do you use?
Pick your app above. We remember it, so next time the button says “Install in …”.
Open Claude Desktop → Settings → Developer → Edit Config, and paste this into claude_desktop_config.json
{
"mcpServers": {
"ghost-inspector": {
"command": "npx",
"args": [
"-y",
"ghost-inspector-mcp"
],
"env": {
"GHOST_INSPECTOR_API_KEY": "your-value",
"GHOST_INSPECTOR_ORG_ID": "your-value",
"GHOST_INSPECTOR_ALLOW_WRITES": "your-value",
"GHOST_INSPECTOR_ALLOW_RUNS": "your-value",
"GHOST_INSPECTOR_BACKUP_DIR": "your-value"
}
}
}
}Run this in your terminal
claude mcp add ghost-inspector --env GHOST_INSPECTOR_API_KEY=your-value --env GHOST_INSPECTOR_ORG_ID=your-value --env GHOST_INSPECTOR_ALLOW_WRITES=your-value --env GHOST_INSPECTOR_ALLOW_RUNS=your-value --env GHOST_INSPECTOR_BACKUP_DIR=your-value -- npx -y ghost-inspector-mcpFill in the empty values before running it.
Or copy the settings yourself
Paste into .cursor/mcp.json in your project, or ~/.cursor/mcp.json
{
"mcpServers": {
"ghost-inspector": {
"command": "npx",
"args": [
"-y",
"ghost-inspector-mcp"
],
"env": {
"GHOST_INSPECTOR_API_KEY": "your-value",
"GHOST_INSPECTOR_ORG_ID": "your-value",
"GHOST_INSPECTOR_ALLOW_WRITES": "your-value",
"GHOST_INSPECTOR_ALLOW_RUNS": "your-value",
"GHOST_INSPECTOR_BACKUP_DIR": "your-value"
}
}
}
}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.
Or copy the settings yourself
Paste into .vscode/mcp.json in your project
{
"servers": {
"ghost-inspector": {
"type": "stdio",
"command": "npx",
"args": [
"-y",
"ghost-inspector-mcp"
],
"env": {
"GHOST_INSPECTOR_API_KEY": "your-value",
"GHOST_INSPECTOR_ORG_ID": "your-value",
"GHOST_INSPECTOR_ALLOW_WRITES": "your-value",
"GHOST_INSPECTOR_ALLOW_RUNS": "your-value",
"GHOST_INSPECTOR_BACKUP_DIR": "your-value"
}
}
}
}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.
This one runs on your computer, and ChatGPT can only connect to servers on the internet. Pick another app.
Your choice stays on this device in a cookie; no account needed.
Values you fill in
- Your personal Ghost Inspector key, from Account Settings then API Access. Read fresh on every call, never written to disk, never echoed back.
GHOST_INSPECTOR_ORG_IDenvOrganization id. Needed only to execute a validation; read it from gi_whoami.GHOST_INSPECTOR_ALLOW_WRITESenvSet to exactly true to let the five write tools act. They are listed either way; anything else keeps the server read-only.GHOST_INSPECTOR_ALLOW_RUNSenvSet to "true" to let gi_run_test execute a stored test against a real environment, which can submit a real form. Deliberately not implied by GHOST_INSPECTOR_ALLOW_WRITES: an edit can be rolled back f…GHOST_INSPECTOR_BACKUP_DIRenvWhere the write path saves the prior definition of every test it touches, credentials removed. Defaults to ~/.ghost-inspector-mcp/backups, created owner-only.
These settings are generated from the maker’s registry entry. If the README says otherwise, follow the README.
What it can do
Runs on your computer; the tool list appears in your AI app after you install it.
Basic checksi
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 9, 2026
- ✓ Pass
Maker matches the repo
The registry name was verified with the GitHub account charliemtnez, which owns the repo
- … Not checked yet
Still maintained
We have not read this repo from GitHub yet
- … Not checked yet
Has a licence
We have not read this repo from GitHub yet
- – Not applicable
Endpoint responds
This one runs on your computer; there is no internet endpoint
- – Not applicable
Sign-in with OAuth
Runs on your computer and uses local settings instead
- … Not checked yet
No hidden instructions in tool descriptions
Runs on your computer; we can only read tool lists from internet endpoints
Compared with others in Web & browsersi
- More stars than 0% of the other 1390 servers in this category
- Published to the registry more recently than 44% of the other 1390 servers in this category
- Basic checks equal to or better than 100% of the other 1390 servers in this category
Compared with every active server in this category in the registry. Stars count only when the publisher owns the repo.
Common questions
Is Ghost Inspector MCP safe?
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.
What keys or codes does it need?
You need to fill in: GHOST_INSPECTOR_API_KEY
Does it run on my computer or in the cloud?
It runs on your computer. Your AI app starts it when needed, and data does not pass through the maker’s servers (unless it calls an online service itself).
Is it still maintained?
The GitHub repo last changed –, and the latest version (0.4.1) reached the registry 41 days ago.
Which apps can use it?
Apps that support MCP, such as Claude Desktop, Claude Code, Cursor and VS Code. You also need Node.js on your computer.
What can I use instead?
In the same category: Browser Use, Chrome DevTools MCP, MCP Server Browser
Alternatives
Servers in the same category from other makers, sorted by stars.
Reading a card:↓ Downloads per weeki★ GitHub starsiThree pillars: reviews · checks · usageiUpdated = latest version published to the registryi
Chrome DevTools MCP
Lets AI use Chrome’s developer tools to inspect pages, find what makes them slow and spot errors. Made by the Chrome DevTools team.
Runs on your computer
README from the maker
Open the README
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.
ghost-inspector-mcp
An MCP server for the Ghost Inspector API, so you can work with end-to-end browser tests from whatever agent you already use — Claude, OpenAI, OpenCode, your own automation — instead of clicking through the web UI.
Status
Twenty tools. Fourteen only read, five write, and one runs a test for real. All of them are always listed — the gated ones refuse when called without their opt-in rather than hiding, so nothing has to be inferred from an absent tool.
The table is a map of the surface. Each tool's own description, which is what your agent actually reads, is where the detail and the gotchas live.
Understand an account
| Tool | Access | What it does |
|---|---|---|
gi_whoami | read | Verifies your API key, lists the organizations it can reach with their ids, and reports which gates are open. Start here when something is misconfigured, or when an agent tells you this server cannot modify anything. |
gi_inventory | read | The whole account as a folder → suite tree, with per-suite counts of passing / failing / module / not-yet-run tests and the ids and names of the failing ones. Filter by folder, or ask for failing suites only. |
gi_find_tests | read | Tests by name, folder, suite or what their own steps do (command, any fallback selector, value), with the ids every other tool takes. |
gi_module_usage | read | The reverse index of execute steps: for every imported test, who imports it directly and its full transitive blast radius, with ids. Also finds modules nobody imports, imported tests missing the import-only flag, broken references, and cycles. Filter the listing by folder or suite; the radius stays account-wide. One request per test. |
gi_get_test | read | One test's stored definition, identity and state — including the dateUpdated that gi_update_test requires as its concurrency token. Call it before composing any edit. Up to 20 at once; expandModules inlines what a run executes, step by step, with its owner. |
Find what is wrong
| Tool | Access | What it does |
|---|---|---|
gi_stale_tests | read | Splits red tests into stale and genuinely broken by comparing the whole execute chain's dateUpdated against each test's last run. Also finds passing tests whose result predates a change. Filter by folder or suite. One request per test. |
gi_vacuous_tests | read | Green tests that prove nothing, in three separate classes: runs zero steps; runs its steps but contains no assertion at all; or a shortlist whose lone final assertion may have been true before the test did anything. Filter by folder or suite. |
gi_test_result | read | Why one test is red: the failing step, its error, the selectors it was *authored* with rather than only the one that resolved, and which test or module actually owns the step — mapped by position against the current definition, never guessed. Leads with a staleness verdict, because a result that predates a change is not evidence. Returns the run's screenshot, video, URLs and console. Up to 20 at once. |
gi_test_history | read | A test's runs, newest first, up to 500: each verdict and failing step, the last pass, and the first failure of the current red streak. States how far back it could see. |
gi_failure_groups | read | Red tests grouped by when they began failing, across suites and folders, with their common errors and targets — many reds within hours usually share one cause. |
Fix it
| Tool | Access | What it does |
|---|---|---|
gi_propose_repair | read | Turns a diagnosis into a concrete proposal: the rewritten step, which test owns it, and the token to write it. Applies nothing, and refuses on a stale diagnosis or a step it cannot locate. |
gi_plan_test | read | Exactly what gi_validate_test would send — modules inlined, {{variables}} resolved, all three submit-guard layers applied — and whether it would be refused. Starts no browser and needs no organization id. |
gi_validate_test | read¹ | Runs a definition through on-demand execution, which executes and discards it, and reports every step. Replicates the suite's configuration and variables, and guards against submitting in three layers (see the safety model). |
gi_screenshot_status | read | A test's screenshot comparison: the settings in force (inherited from the suite when the test leaves them unset), the measured difference against the threshold, the image it was compared against, and the baseline the next run will use — which differ right after an accept. Up to 20 at once. |
gi_screenshot_diff | read | Where a screenshot changed: compares a result's full-size image with its baseline pixel by pixel and returns the changed bands plus full-size crops of the largest, baseline above current. |
gi_update_test | write | Replaces a test's steps, renames it or changes its start URL, behind four guards and a concurrency token. The prior definition is saved to an owner-only file. |
gi_move_suite | write | Moves a suite with its tests to another folder. Reversible; returns the prior folder so the undo is one call. |
gi_move_test | write | Moves one test to another suite — also how to retire one. Reversible; says whether the destination runs on a schedule, since the test starts running with it. |
gi_create_suite | write | Creates an empty suite, in a folder if you name one. Refuses a same-named sibling unless you insist. |
gi_duplicate_test | write | Copies a test, places it in a suite, renames it and optionally re-points its start URL in one call. The only way to get a new test — Ghost Inspector has no create endpoint — so a source test is required. Clears the copy's schedule by default. |
gi_accept_screenshot | write | Makes the latest screenshot the new baseline — only if it is the result you looked at, still the latest and finished, with a failing comparison. Returns the baseline it replaced, since the API cannot restore one. |
gi_run_test | run | Executes a test exactly as saved and waits for the verdict. Its own gate, separate from writes. A test that submits a form is refused unless you confirm on that call. |
¹ gi_validate_test saves nothing, but it drives a real browser against a real URL, so it is not marked read-only.
The six write tools refuse unless GHOST_INSPECTOR_ALLOW_WRITES is exactly true, and gi_run_test refuses unless GHOST_INSPECTOR_ALLOW_RUNS is. A refusal changes nothing and names the variable to set. gi_whoami reports both gates.
Not included, on purpose. Deletion of any kind. DELETE /suites/{id}/ cascades to every test in the suite with no undo, and that blast radius does not belong behind an agent; deleting a test is left out for the same reason, since there is no version history to restore from.
Creating a test from nothing is not possible. Ghost Inspector exposes no create endpoint — POST /tests/ returns the test listing, the organization- and folder-scoped variants return 404, and the vendor documents update, duplicate and delete with no create. gi_duplicate_test is the supported route: copy an existing test, place it, rename it. It is named for what it does, because calling it "create" would set the wrong expectation about needing a source.
Dating a regression back to its last green run is gi_test_history. Old results are purged, so every answer carries its horizon: how far back it walked, and whether that was the end of what Ghost Inspector retains or only the end of what was asked for.
What you can ask for
You talk to your agent, not to the tools. These are the questions the server is built to answer:
- *"Which of my failing tests are actually broken, and which just haven't run since someone edited them?"* — the distinction the dashboard cannot make, and the reason a triage session usually starts here.
- *"Why is the checkout test red?"* — the failing step, its error, and which test or module owns it.
- *"If I change this shared module, what breaks?"* — direct importers and the full transitive reach, which is normally much larger.
- *"Which of my green tests aren't really testing anything?"* — three separate ways a test can pass while proving nothing.
- *"Fix that selector."* — propose a change, run it without saving to check it resolves, apply it behind the guards, then run the test to confirm. Each step is a separate tool, and the ones that change or execute anything need you to opt in first.
A note on scale. This server earns its place on accounts that have accumulated mess: hundreds of tests, shared modules with unclear ownership, a failing list nobody has triaged in months. On a small, well-tended account — a couple of dozen tests, no modules, everything green — gi_stale_tests, gi_module_usage and gi_vacuous_tests will correctly return nothing, and the server will look like it does very little. That is the honest answer for that account, not a malfunction.
Why this exists
Ghost Inspector's API is small and stable, so a 1:1 wrapper would add nothing over curl. This server is for the three things curl cannot give you:
- Aggregations the API does not provide — the account as a folder → suite tree with honest counts, the reverse index of which tests import each module, and red tests split into genuinely broken versus merely out of date.
- Guardrails on the write path — there is no version history for test steps and no recycle bin. Overwrites are forever.
- Tool descriptions that teach the calling model how not to break things — the accumulated gotchas ship with the tool, so every agent gets them for free instead of learning them the expensive way.
Other community wrappers of this API exist. The difference here is the posture: nothing is written or executed until you opt in, no deletion at any opt-in level, and every write behind guards that cannot be turned off.
Two worked examples of that third point, because it is the whole thesis.
Marking a test Import Only — Ghost Inspector's way of saying "this is a module, other tests import its steps" — *deletes its stored results*. Every module is therefore permanently "never executed": no results, passing not a boolean, last-run date pinned to the 1970-01-01 epoch sentinel. The obvious implementation of stale-test detection sorts by last-run date, so it reports every module in your account as the deadest, most broken thing in it, and advises deleting exactly the steps all your live tests share. This server knows that, and ships the predicate that prevents it.
And a test whose steps are only execute calls into modules with no steps runs zero steps and passes, because nothing can fail. The dashboard shows it green while it asserts nothing, which is worse than red because nobody investigates green. Emptying one shared module does that to every test importing it, silently and all at once.
That is the smallest of three ways a test can be hollow. On a real account of a few hundred tests, gi_vacuous_tests found that the largest group by far was not this one but tests that run every step and contain no assertion at all — they can only fail if a step errors. A third group asserts only on its final step, which may well have been true before the test did anything. All of them green.
Install
Requires Node 18+. There is nothing to install ahead of time — your MCP client launches the server with:
npx -y ghost-inspector-mcpThat always runs the latest release. To pin one, which is what a team sharing a setup should do, name it: npx -y ghost-inspector-mcp@0.4.1.
[![Install in VS Code](https://im
Only the beginning is shown; read the rest in the repo