Hoppscotch now ships a Model Context Protocol server. Model Context Protocol, or MCP, is an open standard that lets an AI agent call external tools through a defined interface. With the server running, a host, meaning the app you run the agent in, such as Claude Code, Claude Desktop, or Cursor, can work with Hoppscotch directly, from the same window where you write code.

The server turns your Hoppscotch workspace into tools an agent can call. It reads and writes collections, requests, and environments, manages teams, runs real HTTP requests, and generates code and documentation. It works against Hoppscotch Cloud and any self-hosted instance, and when a tool needs your account it signs you in through the browser by default, so there is no token to copy to get started.

Requests and responses

Ask the agent to run a request and it calls the execute_request tool. A prompt like "Execute a GET request to https://api.github.com/users/octocat and show me the response" sends the call and returns the response into the conversation. The tool takes a raw method and URL, applies any authentication you pass, and substitutes environment variables into the URL, the header values, and the body. Substitution reads your personal environments, on Hoppscotch Cloud and self-hosted alike. A team environment id is rejected as not found.

Because it is a real HTTP client, it ships with a guard. By default it refuses targets that resolve to the machine's own address, private and internal network ranges, and the cloud metadata endpoint that holds instance credentials, across both IPv4 and IPv6. It resolves the name first and stops if resolution fails, connects only to the address it already checked, and does not follow redirects, so a permitted host cannot bounce the request to an internal one. The guard still reaches any public host, using the request's own credentials, so treat what the agent sends like a shell command.

A companion tool, validate_response, checks a response against conditions you set, such as a status code or a time budget. It runs its own request rather than reading a result from an earlier call, so the same guard applies to it. Validating a request you already ran sends it again, so one that creates a record creates two. Responses are capped at 5 MB and a request times out after 30 seconds, and both limits are configurable.

Collections, environments, and teams

Most of the tools manage the things you already keep in Hoppscotch. The agent can create, read, update, delete, and move collections and requests, in your personal space or in a team, and it can import and export whole collections. It can manage environment variables across your stages, and it can create teams, invite members, and set roles.

Hoppscotch Cloud and self-hosted are nearly at parity. Two tools are the exception. Fetching a single personal collection with get_user_collection errors on Cloud for now, because the backend fails to serialize the collection's data there. In the meantime, list_user_collections still lists your root collections, and export_user_collection works for a known id. And search_team_requests is self-hosted only, because the Cloud backend rejects that query. Everything else works on both.

Code and documentation

The server also writes code for a request. generate_code returns a runnable snippet in curl, JavaScript, Python, Go, or Rust. It keeps live credentials in the snippet by default, so what you get runs as is. Set redactCredentials when you plan to paste the snippet somewhere shared, and the values are masked.

generate_documentation works the other way around. It produces Markdown for a request and masks credentials by default, because documentation tends to be shared. One tool is meant to run and the other to circulate, so they start from opposite defaults. Masking is pattern-based either way. It catches auth values and recognized secret fields, not every place a secret can hide, so look over anything you share.

Tools and profiles

There are 53 tools in all. They fall into a few groups:

• Collections and requests, personal or team
• Environments and their variables
• Teams, members, and roles
• Request execution and response validation
• Code and documentation generation

You do not have to expose all of them. A profile sets the surface. The default is core, with 39 tools, covering the create, read, update, and delete operations, request execution, and code and documentation generation you need for day-to-day API work, plus read-only team discovery.

core leaves out team administration, meaning creating, renaming, or deleting whole teams and changing who belongs to them, along with the advanced collection operations. The smaller minimal profile drops to 22 tools. standard gives up request execution, code and documentation generation, and the tools that read and edit individual requests, and gains team administration, the advanced collection operations, and team-request search in return. full is all 53. core and standard are two branches of full rather than steps on a ladder, and an unrecognized profile name falls back to core rather than opening everything up.

What runs by default

core is the default because it is the lean surface, not because it is read-only. It still includes write tools. A default agent can create, update, or delete a team collection, and those tools run on the first call. The server does not add a confirmation step of its own. Every tool does carry hints, marking whether it only reads, whether it is destructive, whether repeating it is safe, and whether it reaches outside Hoppscotch, and a host can use those hints to ask you first. Whether it asks is the host's choice.

Secret environment values are the other thing to scope. By default they substitute into requests freely, the same as any other variable. You can set an allowlist of origins that are allowed to receive them, and the server then refuses to send a secret to any origin outside that list. A request that carries no secret reaches its target either way. The server also removes secret values from a response before the agent sees them, but that pass is best-effort and covers only environment values you marked secret. A credential you write straight into a header or into the authentication block is never in that set, so do not rely on the response pass for anything sensitive.

One more control helps when you open untrusted code. If the working directory holds its own environment file, the server reads it by default. Set HOPPSCOTCH_STRICT_ENV to "true" to make it ignore trust-sensitive values from that file, such as the sign-in target, the request guard, and the secret allowlist, so a hostile repository cannot repoint them.

Getting started

The server runs as a local process your host starts. Point your MCP host at it with one command:

{
  "mcpServers": {
    "hoppscotch": {
      "command": "npx",
      "args": ["-y", "@hoppscotch/mcp-server"]
    }
  }
}

When a tool needs your Hoppscotch account, the server uses HOPPSCOTCH_ACCESS_TOKEN if you set one, or a session it has already cached. With neither, it opens the Hoppscotch device-login page in your browser. Sign in once and the session is cached on your machine, so later calls skip the browser. In a session with no browser to open, like CI or SSH, it fails with instructions instead. For a self-hosted instance, add HOPPSCOTCH_SERVER_URL with your instance address. You need Node 22 or newer. Per-client setup for the different hosts lives in the Hoppscotch documentation.

What's next?

This first release speaks over a local process, which fits an agent running on your own machine. Running it remotely, so an agent on another machine can reach it, is on our list to explore. If there is a workflow you want it to cover, tell us.

The server is open source under the MIT license. Try it, and send feedback to hello@hoppscotch.io or open an issue on our GitHub repository.