Dev-Server MCPs: Next.js DevTools, MobileBuildMCP and Hugging Face

Dev-server MCP servers connect a coding agent to the toolchain already running your app. next-devtools-mcp reads live errors, routes and logs from the /_next/mcp endpoint built into Next.js 16+ dev servers. MobileBuildMCP builds, launches and tests iOS apps on simulators. The Hugging Face MCP server searches the Hub. Each lets the agent check its edits against the real toolchain.

This page is for developers who build web or iOS apps with an agent, and for tech leads who decide which servers a team installs. The agent edits a Server Component, reports “done”, and you find the hydration error in the browser. Or it changes a SwiftUI view, and you are the one who runs Xcode to learn that the UI test now fails. In both cases you are the loop between the toolchain and the agent. These servers take you out of it. If you have not connected an MCP server to your agent before, start with how MCP works in Claude Code, Codex and Cursor.

What you’ll walk away with from dev-server MCPs

Verified install lines for the three servers in Claude Code, Codex and Cursor
A copy-paste prompt that builds an iOS app for the iPhone 16 simulator, runs the UI tests and fixes the first failure
The dev-server-in-the-loop workflow for Next.js: every edit is checked against the running server before the agent moves on
The measured tool-schema size of each local server, and when the CLI route is the cheaper option
The traps: the renamed MobileBuildMCP package, the 60-second Codex timeout, and the unquoted ?login URL

Which dev-server MCP answers which question?

Install the server for the stack you already run. None of them replaces your tests; each one gives the agent evidence it could not see before.

Server	Question it answers for the agent	Transport	Requirements	Popularity (2026-09-26)
Next.js DevTools MCP (`next-devtools-mcp`, Vercel)	What errors does the running app show right now, and which routes exist?	Local stdio (npm 0.4.0), proxies the dev server’s `/_next/mcp`	Node.js 20.19+; Next.js 16+ with `npm run dev` running	★823
MobileBuildMCP (`mobilebuildmcp`, Sentry; formerly XcodeBuildMCP)	Does the iOS app build, launch and pass its tests on this simulator?	Local stdio (npm 2.7.1), also a CLI	macOS 14.5+, Xcode 16+, Node.js 18+ (not for the Homebrew install)	★6.4k
Hugging Face MCP (Hugging Face)	Which model, dataset or Space on the Hub fits this task?	Remote HTTP, `https://huggingface.co/mcp`	A Hugging Face account for authenticated tools	★298

Popularity is GitHub stars read through the GitHub search API on 2026-09-26 (6,427, 823 and 298). Stars measure attention on a repository, not use of the server. For component registries, the fourth server in this family is shadcn/ui MCP, which has its own page.

Install Next.js DevTools MCP

next-devtools-mcp is a thin connector. It scans common ports for Next.js 16+ dev servers, lists the runtime tools each one exposes at /_next/mcp, and calls them. Next.js 16+ enables that endpoint by default, so the dev server needs no configuration.

# Terminal, repo root. Project scope writes .mcp.json so the team reviews it
claude mcp add -s project next-devtools -- npx -y next-devtools-mcp@latest

codex mcp add next-devtools -- npx -y next-devtools-mcp@latest

On Windows 11 the vendor README adds env = { SystemRoot="C:\\Windows", PROGRAMFILES="C:\\Program Files" } and startup_timeout_ms = 20_000 to the server’s block in config.toml.

{ "mcpServers": { "next-devtools": { "command": "npx", "args": ["-y", "next-devtools-mcp@latest"] } } }

The server has four tools. Two do the work: nextjs_index discovers running dev servers and their tools, and nextjs_call runs one of them. The runtime tools come from Next.js itself and vary by version; the README lists get_errors (build, runtime and type errors), get_logs (the path to the dev log with browser console and server output), get_page_metadata, get_project_metadata and get_server_action_by_id. The other two are gateways that only point the agent elsewhere: nextjs_docs points at the version-matched docs Next.js bundles in node_modules/next/dist/docs/, and browser_eval tells the agent how to install and run the agent-browser CLI.

The server collects anonymous usage telemetry (tool names, not arguments or code). Set NEXT_TELEMETRY_DISABLED=1 in your shell profile to opt out.

Install MobileBuildMCP

MobileBuildMCP is one package with two modes: an MCP server (mobilebuildmcp mcp) and a CLI for the terminal. Version 2.7.1 (2026-09-23) renamed the project from XcodeBuildMCP. The package, binaries, MOBILEBUILDMCP_* environment variables and the .mobilebuildmcp/config.yaml project file all use the new name.

claude mcp add -s project mobilebuild -- npx -y mobilebuildmcp@latest mcp

codex mcp add mobilebuild -- npx -y mobilebuildmcp@latest mcp

Builds and test runs outlast Codex’s default tool timeout. Add the timeout to the server’s own block; the vendor docs note that Codex ignores a top-level tool_timeout_sec for MCP calls:

[mcp_servers.mobilebuild]
command = "npx"
args = ["-y", "mobilebuildmcp@latest", "mcp"]
tool_timeout_sec = 600

// .cursor/mcp.json in the workspace root
{ "mcpServers": { "mobilebuild": { "command": "npx", "args": ["-y", "mobilebuildmcp@latest", "mcp"] } } }

In the global ~/.cursor/mcp.json, the vendor docs add "env": { "MOBILEBUILDMCP_CWD": "${workspaceFolder}" } so the server starts in the open workspace. The docs page still spells that variable XCODEBUILDMCP_CWD; the rename changed every XCODEBUILDMCP_* variable.

With Homebrew (brew tap getsentry/xcodebuildmcp && brew install mobilebuildmcp), replace the npx command with mobilebuildmcp and the arguments with mcp. That skips the npx download check on every start.

Commit the build context once, so every session and every teammate targets the same scheme and simulator. Run mobilebuildmcp setup for an interactive wizard, or write the file yourself:

# .mobilebuildmcp/config.yaml, committed at the workspace root
schemaVersion: 1
enabledWorkflows: ["simulator"]
sessionDefaults:
  projectPath: "./Shop.xcodeproj"
  scheme: "Shop"
  simulatorName: "iPhone 16"
sentryDisabled: true

simulatorName is the portable selector: simulator UUIDs differ per machine, names do not. enabledWorkflows defaults to ["simulator"], which carries 20 tools, among them build_sim, build_run_sim, test_sim, screenshot and snapshot_ui. Add "ui-automation" only when the agent must tap, swipe and type in the running app. sentryDisabled: true turns off the server’s internal error telemetry, which the vendor limits to the server’s own faults.

Build for the iPhone 16 simulator, run the UI tests, fix the first failure

This is the example to try first. It uses MobileBuildMCP alone, and it ends with a green test run you did not have to watch.

Use the mobilebuild MCP server. Project Shop.xcodeproj, scheme Shop.
1. Call list_sims. If no "iPhone 16" simulator exists, stop and tell me which iPhone simulators are installed. Do not create one.
2. Set session defaults for this project, scheme and simulator, boot it, and run build_sim. If the build fails, fix the first compiler error only, rebuild, and report.
3. Run test_sim with extraArgs ["-only-testing:ShopUITests"]. List every failure with its test name, assertion message and file:line.
4. Take the FIRST failure only. Read the test and the code under test, explain the cause in two sentences, and decide whether the app or the test is wrong. If the test encodes the intended behaviour, fix the app. Never delete, skip or weaken an assertion.
5. Rerun test_sim with -only-testing for that one test, then for the whole ShopUITests target. Report pass/fail counts before and after, and the path of the .xcresult bundle from the final run.

What you should see: session_set_defaults, boot_sim, build_sim, then test_sim. The test result lists each failure as the test name, the assertion message and the source line, followed by the paths of the build log, the .xcresult result bundle and the test products under ~/Library/Developer/MobileBuildMCP/workspaces/. Then a short diagnosis, one diff, and two reruns. If the agent proposes changing an assertion, it has broken rule 4; reject the diff.

When the failure is visual, add a second step:

For the failing UI test, run build_run_sim, navigate to the screen the test exercises, and call snapshot_ui and screenshot.
Compare the accessibility identifiers in the snapshot with the ones the test queries. Report any identifier the test expects that is missing on screen, and the view that should carry it.

For the scripted, CI-shaped side of the same work (one build-and-test script per platform, pinned simulators, trimmed logs), see native iOS and Android recipes.

Install Hugging Face MCP

The Hugging Face server is hosted. It connects the agent to the Hub “and thousands of Gradio AI Applications” (README). Pick OAuth for a person at a keyboard and a token for headless runs.

# OAuth: quote the URL, or zsh treats ? as a glob and stops with "no matches found"
claude mcp add -s project --transport http huggingface "https://huggingface.co/mcp?login"

Token instead of OAuth. Single quotes keep the variable unexpanded in .mcp.json; Claude Code expands it at launch:

claude mcp add -s project --transport http huggingface https://huggingface.co/mcp \
  -H 'Authorization: Bearer ${HF_TOKEN}'

codex mcp add huggingface --url https://huggingface.co/mcp --bearer-token-env-var HF_TOKEN

This writes bearer_token_env_var = "HF_TOKEN". The README documents no Codex line. For OAuth, adding the ?login URL and running codex mcp login huggingface follows the Claude Code pattern but was not tested.

// .cursor/mcp.json; the same config the README's one-click Cursor install link adds
{ "mcpServers": { "huggingface": { "url": "https://huggingface.co/mcp?login" } } }

The README’s token variant uses "url": "https://huggingface.co/mcp" with an Authorization: Bearer header. Keep the token in an environment variable, not in the file.

After installing, choose the tools and Spaces the server exposes at huggingface.co/settings/mcp. Add ?no_image_content=true to the URL to strip image blocks returned by Gradio Spaces. For the token route, create a read-only token: the tools that create repositories, run Jobs or start sandboxes need authentication, and a write token lets the agent use them.

Use the huggingface MCP server, read-only. I need a sentence-embedding model for semantic search over English support tickets, running on CPU in under 100 ms per ticket.
Search the Hub for candidates. For the five most downloaded, report: repo ID, parameter count, embedding size, licence exactly as the model card states it, and last update date.
Do not recommend any model whose card has no licence. Then write eval/embeddings_eval.py that scores each shortlisted model on tests/fixtures/tickets_sample.jsonl (recall@5 against the labelled duplicates) and times it on CPU. Do not download any model until I approve the shortlist.

The Hub answers “what exists”; your eval answers “what works here”. The licence check matters because the weights licence lives on the model card, and it can differ from the licence of the code repository. Hugging Face also publishes skills that drive the hf CLI (in Claude Code: /plugin marketplace add huggingface/skills, then /plugin install hf-cli@huggingface-skills). They are the better fit when the agent must download, upload or run Jobs rather than search. The huggingface-skills entry in the Claude Marketplace directory showed 34,575 installs on 2026-09-26.

Run the dev server in the loop

The pattern behind all three servers: the agent never reports “done” on the strength of its own diff. It asks the running toolchain first. Here it is for Next.js.

Start the dev server yourself. Run npm run dev in a second terminal and leave it running. Next.js 16+ serves /_next/mcp on the same port. Starting it yourself keeps one server per worktree and a port you know.
Write the acceptance check first. The agent adds or names the test that proves the change: a Playwright test for a route, a unit test for a Server Action. It runs it and confirms it fails. See acceptance criteria an agent can check.

Edit, then ask the server. After each edit, the agent calls nextjs_call with get_errors on your port. Zero build, runtime and type errors is the gate to continue. A new error goes back into the same turn, with the file and line the server reports.

The Next.js dev server is running on port 3000. Use the next-devtools MCP server.
Task: add an "Order history" page at /account/orders that lists the signed-in user's orders from getOrders() in lib/orders.ts, newest first, 20 per page.
Before editing, call nextjs_index and nextjs_call get_page_metadata to see the existing routes, and call nextjs_docs and read the docs it points to in node_modules/next/dist/docs/ rather than relying on memory.
First write tests/e2e/orders.spec.ts and run it; it must fail.
After EVERY file edit, call nextjs_call with toolName get_errors on port 3000. If it returns any error, fix it before the next edit.
When get_errors is empty, request /account/orders, check the dev log from get_logs for new warnings, then run the e2e test and npm run typecheck.
Report the final get_errors output, the test result and the typecheck result. Do not start or stop the dev server.

Check the page, not only the server. Server-side errors are one half; hydration mismatches and client exceptions show up in the browser. browser_eval points the agent at agent-browser, or use Playwright MCP to load the route and read the console.
Hand over evidence. The pull request carries the failing-then-passing test, the empty get_errors output and the typecheck result, as in an evidence bundle. CI then reruns tests, types and lint; the dev-server check never replaces them.

The loop is identical in all three agents. What differs is how you keep it safe and fast:

Put the rule in CLAUDE.md so you do not repeat it in every prompt: “After editing files under app/, call nextjs_call get_errors on the dev server before reporting.” Start the task in plan mode when it touches more than a few routes, so you approve the file list before edits begin.

Put the same rule in AGENTS.md. For MobileBuildMCP, keep tool_timeout_sec in the server block; without it, a long test_sim run ends in a timeout that the agent may misread as a test failure.

Put the rule in a project rule under .cursor/rules/. Review each diff in the editor as usual; the get_errors output in the agent’s transcript tells you whether the server saw a clean build.

How do you know the agent’s change works?

A test failed first, then passed. For Next.js, an e2e or unit test; for iOS, the test_sim run before and after. A test that only passes proves nothing about this change.
The toolchain agrees, not the agent. The final get_errors output is empty, or the final test_sim reports zero failures and names its .xcresult bundle. Ask for the raw output in the report, not a summary of it.
Assertions did not move. In review, diff the test files first. A fix that edits an assertion, adds a skip or widens a timeout needs a reason in the pull request.
CI stays the merge gate. Tests, npm run typecheck, lint and the iOS build script run in CI for every change. The MCP servers make the agent’s inner loop honest; they do not sign off anything.
A person approves. The code owner reviews the evidence and merges. For the review checklist, see how to review an agent’s pull request.

How much context do dev-server MCPs cost?

Measured on 2026-09-26 as the character count of each server’s tools/list tools array, rounded because the exact figure shifts by a few percent with serialization (compact JSON versus the full JSON-RPC response):

Server	Tools	Size of the `tools/list` reply
`next-devtools-mcp` 0.4.0	4	About 6,000 characters
`mobilebuildmcp` 2.7.1, default `simulator` workflow	24 (20 simulator tools plus 4 session-default tools)	About 115,000 characters; about 16,000 without the `outputSchema` blocks
`mobilebuildmcp` 2.7.1, `simulator` plus `ui-automation`	36	About 235,000 characters; about 28,000 without the `outputSchema` blocks

The Next.js server is small enough to leave on. MobileBuildMCP’s names, descriptions and input schemas are modest, but its output schemas are large. Claude Code 2.1.283 and codex-cli 0.157.1 both have MCP tool search on, which defers schemas until a tool is needed; run /context in Claude Code before and after adding the server to see what your session actually pays. Keep enabledWorkflows to what the task needs: adding ui-automation alone roughly doubles the reply.

The cheaper route for iOS is the CLI: npx -y mobilebuildmcp@latest init installs an optional CLI skill that teaches the agent to run mobilebuildmcp commands (for example mobilebuildmcp simulator build --scheme Shop --project-path ./Shop.xcodeproj) through the shell. Use the MCP server when you want stateful session defaults and structured test results; use the CLI skill when context is tight. More techniques are in reducing MCP token cost.

What breaks with dev-server MCPs, and how do you recover?

[error] No server info found from nextjs_index. No Next.js 16+ dev server is running, or it failed to start. Start it with npm run dev, confirm the Next.js version is 16 or later (earlier versions have no /_next/mcp), and check the terminal for startup errors. nextjs_docs and browser_eval work without a server.

The agent reads errors from the wrong app. nextjs_index scans common ports, so with two worktrees running it finds two servers. Name the port in the prompt, as the dev-loop prompt above does.

ERR_MODULE_NOT_FOUND referencing next-devtools-mcp/dist. A stale npx cache. Clear the npx cache and restart the agent; the README says the server then reinstalls cleanly.

Codex reports timed out awaiting tools/call after 60s on a build. Add tool_timeout_sec = 600 inside [mcp_servers.mobilebuild], not at the top level of config.toml, then restart the session.

MobileBuildMCP ignores your environment variables or config. They still use the old name. Rename XCODEBUILDMCP_* to MOBILEBUILDMCP_* and move .xcodebuildmcp/ to .mobilebuildmcp/. Then confirm the package: xcodebuildmcp is frozen at 2.7.0.

list_sims has no iPhone 16. Simulator devices depend on the installed Xcode runtimes. Pick an installed device and update simulatorName in the committed config, or create the device in Xcode yourself. Do not let the agent download runtimes as a side effect of a test task.

Device builds fail on signing. The device tools need code signing configured in Xcode first. Keep agent runs on simulators unless signing is already set up.

claude mcp add … https://huggingface.co/mcp?login fails with no matches found. zsh read ? as a glob. Quote the URL.

The agent follows instructions found in a model card or a Space’s output. Hub content is written by anyone and reaches the model as text it may treat as instructions. Keep the token read-only, do not combine the Hugging Face server with write-capable servers in the same session, and read MCP security before connecting it. Connection problems in general are covered in MCP connection issues.

xcodebuildmcp and the XcodeBuildMCP server name in older guides: the old package, frozen at 2.7.0. Use mobilebuildmcp (2.7.1).
upgrade_nextjs_16, enable_cache_components and init tools in next-devtools-mcp: removed in 0.4.0. Upgrade and Cache Components workflows now ship as agent skills.
@vercel/mcp: not on npm. Vercel’s platform server (projects, deployments, logs) is a separate, remote server; next-devtools-mcp only talks to your local dev server.
claude mcp add --url …: --url is Codex’s flag. Claude Code uses --transport http <name> <url>.
-H "Authorization: Bearer hf_…" pasted with a real token: it lands in .mcp.json and your shell history. Reference ${HF_TOKEN} instead.
A top-level tool_timeout_sec in Codex config.toml: ignored for MCP tool calls. It belongs in the server block.
/plugin install hf-cli@huggingface/skills, as some Hugging Face instructions spell it: fails on Claude Code 2.1.283 with Plugin "hf-cli" not found. The marketplace is named huggingface-skills.
claude mcp add -e KEY=value mobilebuild -- …: -e takes several values, so it swallows the server name. Put -e after the name, as claude mcp add --help shows.

Where to go next with dev-server MCPs

shadcn/ui MCP Add components from shadcn and custom registries to the Next.js app this loop checks.

agent-browser The CLI that browser_eval points to: let the agent open the page and check it like a user.

Native iOS and Android recipes The scripted build-and-test loop for CI, next to MobileBuildMCP for the agent's inner loop.

Top MCP servers Where these three servers sit among the servers teams install first.