An MCP server for your web app's API traffic (Codex, Claude Code, Cursor)

MCP, the Model Context Protocol, is an open-source standard for connecting AI applications to external systems. Anthropic introduced it on 25 November 2024 (announcement). The project's documentation compares it to a USB-C port for AI applications, one standard connector in place of a custom integration for every tool (modelcontextprotocol.io).

An MCP server is a program that offers capabilities to an MCP client, which is the AI application, such as Codex, Claude Code, Cursor, Claude or ChatGPT. Servers provide three building blocks (server concepts).

• Tools are functions the model can decide to call, such as searching flights or listing endpoints.
• Resources are read-only data sources that give the application context, such as files or database schemas.
• Prompts are reusable instruction templates that a user invokes.

The protocol uses JSON-RPC messages. The standard transports are stdio, where the client starts the server as a subprocess, and Streamable HTTP for remote servers (transports). A server that runs through npx, like the Netraptor one, is a stdio server. The client launches it and talks to it over standard input and output.

Agents are good at writing code against an API and poor at guessing what your app's API actually does. If you only describe the app in words, the agent invents endpoints. If you paste a big HAR file, you spend context on thousands of requests that do not matter. The Netraptor server lets the agent ask for exactly what it needs from traffic you recorded in your own browser.

The server is read-only and exposes five tools.

• list_sessions lists your recorded sessions.
• list_endpoints lists the endpoints, with IDs parameterized like /users/{id}.
• get_endpoint returns the detail for one endpoint.
• search finds requests across your recorded traffic.
• get_request returns a single recorded request.

Example questions an agent can now answer from real data: "which endpoints does the orders page call?", "show me a real response from GET /api/orders/{id}" and "find requests that returned 500 in my last session". That makes it easier to write a typed client, a mock server, a test or an integration against the API your frontend already uses.

The local MCP server is a Pro feature. Free covers recording, filters and exports (Postman, HAR, curl), and Pro is a one-time $29.99 purchase with no subscription.

Pair the server first, as described in the steps above. Then add the local stdio server with the Codex CLI (official Codex MCP documentation).

codex mcp add netraptor -- npx -y @branch42-labs/netraptor-mcp

Run codex mcp list to verify that netraptor is configured. Codex shares MCP configuration between its CLI and IDE extension, so you only need to add it once. Keep Chrome running with Netraptor's Local MCP server enabled while Codex uses the tools.

Pair the server first, as described in the steps above. After that, Claude Code needs one command. In Claude Code's syntax, everything after -- is the command that starts the stdio server (Claude Code MCP docs).

claude mcp add netraptor -- npx -y @branch42-labs/netraptor-mcp

By default this stores the server for you in the current project (the local scope). Add --scope user to make it available in every project, or --scope project to write a .mcp.json that your teammates share. Claude Code asks for approval before it uses a project-scoped server from .mcp.json.

Use claude mcp list to see configured servers and /mcp inside a session to check status. If you need to pair again, for example on a new machine, run npx -y @branch42-labs/netraptor-mcp pair <code> with the code from Netraptor's settings.

Cursor reads MCP servers from ~/.cursor/mcp.json for all projects and from .cursor/mcp.json inside a project (Cursor MCP docs). Add this entry.

{
  "mcpServers": {
    "netraptor": {
      "command": "npx",
      "args": ["-y", "@branch42-labs/netraptor-mcp"]
    }
  }
}

Cursor's documentation says you can switch servers on or off from Customize in the sidebar, and read initialization and tool-call output under MCP Logs in the Output panel. Other MCP clients that run stdio servers use the same command and arguments in their own config format.

Google's Chrome DevTools MCP server is a separate project with a different job. According to its README, it lets a coding agent such as Claude or Cursor control and inspect a live Chrome browser. It can analyze network requests, read console messages, take screenshots and record performance traces, and it drives Chrome through Puppeteer.

That makes it a good fit when you want the agent to operate the browser, for example to reproduce a bug, check what a page logs or profile a slow load. The two servers answer different questions.

• DevTools MCP works with a live browser the agent controls, so what the agent sees is what that browser session does right now.
• Netraptor's server serves traffic already recorded from your own logged-in sessions, across page loads and without DevTools open, grouped by endpoint.
• Netraptor's tools are read-only. The agent can look at recorded requests but cannot click, type or send new ones.

You can use both. Let DevTools MCP drive and debug the browser, and let the Netraptor server tell the agent which API calls your app really makes. The Chrome DevTools MCP README also warns that it exposes browser contents to the connected client, so read its disclaimers before you point it at a session with sensitive data.

Recorded traffic can include tokens, cookies and personal data, so the setup is built to stay on your machine. These are the properties of the Netraptor server.

• It listens only on 127.0.0.1:47321. Set NETRAPTOR_MCP_PORT to change the port, and use the same port in the extension settings.
• It accepts WebSocket connections only from a chrome-extension:// origin, and allows one active extension connection.
• The extension and server prove themselves to each other with a mutual HMAC-SHA256 challenge and response, using a 128-bit pairing secret stored in ~/.netraptor/mcp.json with mode 0600.
• Authorization and cookie headers are redacted. Your data stays on your computer.

The agent client you connect still receives what the tools return, and that content goes to whichever model provider the client uses. Claude Code's documentation advises you to verify that you trust each server before connecting it. Record only apps you build, test or are authorized to test, and use a test account for sessions you plan to share with an agent.

A HAR file is a single export of everything in one capture. An OpenAPI spec is a tidy summary, but you have to generate and keep it current. A local MCP server sits between the two. The agent asks for one endpoint or one failing request and gets only that, from the sessions you have recorded.

If you want a list of endpoints to read yourself, see how to find every API endpoint your web app calls. If you want your own site to offer tools to browser agents, that is a different mechanism, covered in what WebMCP is.