## Description ### Motivation File-based stdio MCP servers spawned from a project's `.mcp.json` (e.g. `pnpm run mcp:foo`, or anything using `./tooling_scripts/...`) fail with: ``` Transport creation error: No such file or directory (os error 2) ``` Root cause: when the user's `.mcp.json` doesn't include a `working_directory`, Warp's spawner inherits whatever cwd Warp was launched from rather than the directory the config was discovered in. Two failure modes share this same root cause: - **Repo-relative commands/args** (e.g. `./tooling_scripts/foo`, `node ./src/server.js`) can't be resolved from outside the repo, so `execvp` returns `ENOENT`. - **Workspace-aware launchers** like `pnpm`/`npm`/`yarn` walk up from cwd looking for `package.json` (and workspace manifests). When cwd isn't inside the repo, they bail out before launching the requested script — surfacing as `ENOENT` from the spawner's perspective. `working_directory` is a Warp/VS-Code-style extension; the canonical Anthropic/Cursor MCP schemas don't include it, so most `.mcp.json` files in the wild don't set it. ### Implementation - New helper `FileBasedMCPManager::spawn_root_for_installation(uuid)` returning the discovery root for any file-based install: the repo root for project-scoped configs, the home directory for global configs (Warp and third-party). Returns `None` for non-file-based installs (e.g. cloud-templated ones), leaving them unaffected. Global Warp installs are remapped from `~/.warp/` (Warp internal state) to `~` so all global installs share a consistent cwd. - In `TemplatableMCPServerManager::spawn_server_impl`, default `cli_server.cwd_parameter` from this helper when unset. Single funnel — covers both auto-spawn and the manual UI opt-in path. User-supplied `working_directory` always wins. - ENOENT-aware logging at the spawn site: when `TokioChildProcess::spawn()` fails with `NotFound`, the MCP log file now spells out the server name, the missing executable, the cwd we used, and a hint pointing the user at `working_directory`. The user-surfaced error string is unchanged. - Documented the new defaulting behavior and `working_directory` override in `resources/bundled/skills/add-mcp-server/SKILL.md`. ## Testing Verified spawn-site behavior manually. Demo [here](https://www.loom.com/share/ec01d98ae9114433b8ae87f5f17adfd4)! - Added `test_parse_cli_server_preserves_explicit_working_directory` in `mod_test.rs` to lock in that an explicitly-set `working_directory` round-trips through parsing and won't be clobbered by the new defaulting logic. - Skipped a unit test for the new helper itself — it's a thin lookup over `file_based_servers_by_root` and the sorted-pick policy is straightforward enough to validate manually. - Spawn-site behavior (cwd actually applied, ENOENT log emission) verified manually against a `pnpm`\-based repro. ## Agent Mode - [x] Warp Agent Mode - This PR was created via Warp's AI Agent Mode ## Changelog Entries for Stable CHANGELOG-BUG-FIX: Project-scoped file-based MCP servers now spawn from the repo root by default (and global ones from `~`), so configs with relative commands/args (and workspace launchers like `pnpm`/`npm`) work without an explicit `working_directory`.
3.2 KiB
name, description
| name | description |
|---|---|
| add-mcp-server | Use this skill when helping users add MCP servers to their Warp configuration. |
Adding MCP Servers to Warp
Warp supports MCP servers via native config files. Follow these steps when helping a user add an MCP server.
Step 1: Determine Scope
If the user hasn't specified, ask whether they want to configure the server globally (for all projects) or project-scoped (for a specific repository only).
Config file paths:
- Global (user-scoped):
~/.warp/.mcp.json - Project-scoped:
{repo_root}/.warp/.mcp.json
Step 2: Gather Server Details
If the user hasn't provided the server's connection details, use WebSearch to find the correct configuration for the named server.
If it's unclear whether the server should be run as a local CLI process (stdio transport) or connected to via URL (HTTP/SSE streaming transport), ask the user which they prefer.
Step 3: Check and Prepare the Config File
Check whether the target config file exists.
-
If it does not exist, create it with
mkdir -pfor the directory and initialize it with an emptymcpServerswrapper key:{ "mcpServers": {} } -
If it exists, read it to determine which top-level wrapper key is already in use. Recognized wrapper keys (in order of preference):
mcpServers(preferred)mcp_serversserversmcp.servers(nested under amcpkey)- Flat map (each top-level key is a server name)
Preserve the existing wrapper key when writing. If the existing key is unrecognized or incompatible, switch to
mcpServers.Never remove existing server entries — only add or update the new server.
Step 4: Write the Server Configuration
Command-based server (stdio transport)
{
"mcpServers": {
"server-name": {
"command": "npx",
"args": ["-y", "@scope/package-name"],
"env": {
"API_KEY": "${API_KEY}"
}
}
}
}
By default, Warp spawns stdio servers from the directory the config was discovered in:
- Project-scoped configs (
{repo_root}/.warp/.mcp.json) run from the repo root. - Global configs (
~/.warp/.mcp.json,~/.claude.json, etc.) run from the home directory.
If the server's command or args are relative paths (e.g. ./tooling/mcp/server.js) or the server expects a specific cwd, set working_directory to override the default:
{
"mcpServers": {
"server-name": {
"command": "node",
"args": ["./tooling/mcp/server.js"],
"working_directory": "/absolute/path/to/repo"
}
}
}
URL-based server (HTTP/SSE streaming transport)
{
"mcpServers": {
"server-name": {
"url": "https://example.com/mcp",
"env": {
"API_KEY": "${API_KEY}"
}
}
}
}
For environment variables containing secrets, use ${VAR_NAME} syntax — Warp will substitute the value from the user's environment at runtime.
Notes
- Warp auto-detects changes to
.mcp.jsonfiles on save — no restart required. - Configured servers appear in Warp's Settings under MCP, labeled "Detected from Warp".
- Global config applies across all sessions; project config only applies when working inside that repository.