Docs › Features › MCP server

MCP server

Tiger ships a standalone binary called tiger-mcp that implements the Model Context Protocol. Point it at a collection folder and any MCP-capable client - Claude Desktop, Claude Code, Cursor, or your own agent - can list, inspect, and execute your saved requests without leaving the chat.

How it works

The MCP server is a stdio process. The client launches it as a child process, sends JSON-RPC messages over stdin, and reads responses from stdout. Tiger uses this channel to advertise four tools backed by the same collection files and environment system you use inside the app. Nothing is uploaded or proxied: every request travels directly from the tiger-mcp process to your API.

✓

The server is purely local. Your request payloads, URLs, headers, and response bodies are never sent to any third-party service. The AI client sees only what the tool returns - the same response your browser would see.

What you'd use it for

The point is to let an AI assistant work with the requests your team already maintains in Git - using the real URLs, auth, headers, variables and environments, instead of guessing or pasting curl into the chat. Common uses:

The four tools

Once registered, the MCP server advertises these tools to the connected client:

Tool name Inputs What it returns
list_requests none All requests in the collection, each with its relative path and display name.
list_environments none All environment names defined in the collection's environments/ folder.
get_request path - relative path to the .tiger file The full parsed request as JSON: method, URL template, headers, body, auth, captures, and scripts.
run_request path - relative path to the .tiger file
environment (optional) - environment name to resolve {{variables}}
timeoutMs (optional) - request timeout in milliseconds		 HTTP response: status code, response headers, timing, and the response body.

The AI client can discover every available endpoint by calling list_requests, inspect the details of a specific one with get_request, and fire it - with full variable substitution from any saved environment - using run_request.

Specifying the collection

The server needs to know which collection folder to serve. Pass it as the first argument on the command line, or set the TIGER_COLLECTION environment variable. If neither is provided it defaults to the current working directory. 

# Argument form
tiger-mcp /path/to/your/collection

# Environment-variable form
TIGER_COLLECTION=/path/to/your/collection tiger-mcp

Setting up Claude Desktop

Open claude_desktop_config.json (on macOS this is ~/Library/Application Support/Claude/claude_desktop_config.json) and add a tiger entry under mcpServers: 

{
  "mcpServers": {
    "tiger": {
      "command": "tiger-mcp",
      "args": ["/path/to/your/collection"]
    }
  }
}

If tiger-mcp is not on your PATH, use the full path to the binary instead. After saving the file, quit and relaunch Claude Desktop. The four Tiger tools will appear in the tool picker.

✓

You can register more than one collection by adding additional keys under mcpServers, each pointing the binary at a different folder. Give them distinct names, for example tiger-internal and tiger-public, so the AI client can tell them apart.

Setting up Claude Code

In a project-level .claude/settings.json (or your user-level settings), add the server under the mcpServers key: 

{
  "mcpServers": {
    "tiger": {
      "command": "tiger-mcp",
      "args": ["/path/to/your/collection"]
    }
  }
}

Claude Code picks up the configuration on the next session start. You can also run /mcp from within a session to inspect which servers are connected.

Running via npx (no global install)

If you have cloned the Tiger repository and want to run the MCP server without installing it globally, build the server bundle once and invoke it through Node: 

# Build the MCP bundle (one time, from the Tiger repo root)
npm run build:mcp

# Then register it in your MCP client config like this:
{
  "mcpServers": {
    "tiger": {
      "command": "node",
      "args": [
        "/path/to/tiger/out/mcp/server.mjs",
        "/path/to/your/collection"
      ]
    }
  }
}

The build step writes out/mcp/server.mjs, a self-contained ESM bundle with no dependency on the rest of the Tiger renderer or Electron runtime.

Using environments with run_request

If your requests use {{variable}} placeholders - for a base URL, an auth token, or any other value - pass the environment name when calling run_request: 

// Tool call from an AI client
run_request({
  "path": "auth/get-token.tiger",
  "environment": "staging"
})

The server resolves all variables from the named environment before sending the request. Secret values (marked as hidden in the app) are applied but never echoed back in the tool's return value.

Use list_environments first to discover which environment names are available in the collection.

Example session

The following illustrates what a typical AI-assisted workflow looks like once the server is wired up. 

// 1. Discover what's in the collection
list_requests()
// → [ { path: "users/list-users.tiger", name: "List users" },
//     { path: "users/create-user.tiger", name: "Create user" },
//     { path: "auth/get-token.tiger", name: "Get token" } ]

// 2. Inspect the request you care about
get_request({ path: "users/create-user.tiger" })
// → { method: "POST", url: "{{baseUrl}}/users",
//     headers: { "Content-Type": "application/json" },
//     body: { type: "json", content: "{ \"name\": \"...\", \"email\": \"...\" }" },
//     auth: { type: "bearer", token: "{{token}}" }, ... }

// 3. Run it against the staging environment
run_request({ path: "users/create-user.tiger", environment: "staging" })
// → { status: 201, timing: { total: 142 },
//     headers: { "content-type": "application/json" },
//     body: { "id": "usr_01hx...", "name": "...", "email": "..." } }

What the binary ships with

When you download Tiger, the tiger-mcp binary is bundled inside the application package and unpacked from the Electron asar archive at runtime, so it is always available at the same version as the app itself. The binary entry point is registered in package.json under the bin field ("tiger-mcp": "out/mcp/server.mjs"), meaning a global npm install -g tiger-api-client also places tiger-mcp on your PATH.

!

The MCP server executes requests using the same Node.js HTTP stack as the app. It does not share the app's cookie jar or any in-memory session state. Captured variables from a run_request call are returned in the response but are not automatically written back to the on-disk environment file.

Privacy

The MCP server never phones home. It reads files from the collection folder you specify and sends HTTP requests to whatever host your .tiger files point at - that's all. The AI client receives only the tool return value (status, headers, body). Tiger's optional anonymous analytics cover the desktop app only; tiger-mcp emits no analytics of its own.

Related pages

Collections
How .tiger files are organized on disk and why that makes them git-friendly.
Environments
Named variable sets and how to reference them when calling run_request.
Scripts & chaining
Pre/post-request JavaScript and response captures for variable chaining.
.tiger format
The plain-text file format that the MCP server reads.