SQLite MCP: spawn uvx ENOENT (install uv first)

Not specified by the original author.

TL;DR: uvx is not a system command, it ships with the uv package manager, and the SQLite MCP server needs it to launch. Install uv, confirm uvx --version works in a terminal, then restart your MCP client.

spawn uvx ENOENT

Variant: uvx: command not found.

Fix it

1. Install uv:

curl -LsSf https://astral.sh/uv/install.sh | sh

On Windows: powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex".

2. Verify it is on PATH in a fresh terminal:

uvx --version

Expected: a version number like uv 0.7.x.

3. If the terminal sees it but the MCP client does not, the client was launched before uv updated PATH, or GUI apps do not read your shell profile. Either restart the machine, or put the absolute path to uvx in the client config "command" field. Find it with which uvx.

4. Restart the MCP client.

   Expected: the sqlite server spawns and its tools appear.

When to use this

• The MCP client shows the sqlite server as failed/disconnected immediately at startup.
• Logs or errors mention uvx, ENOENT, or command not found.

When NOT to use this

• The server starts but queries fail. That is a database problem, not a launcher problem.
• You installed the server via pip or another method. Then uvx is not involved at all.

Compatibility

• @modelcontextprotocol/server-sqlite installed via uvx.
• Any MCP client that spawns stdio servers: Claude Desktop, Claude Code, Cursor.

Why it happens

uvx is uv's tool-runner, similar to npx for npm. The official install docs assume it exists, but fresh machines (and especially GUI-launched MCP clients with a minimal PATH) do not have it. The client then fails to spawn the server process at all, which surfaces as ENOENT rather than any database error.

Edge cases

• Homebrew installs of uv usually land on PATH for terminals but not for GUI apps. The absolute-path trick in step 3 is the reliable fix on macOS.
• Corporate machines sometimes block the install script. pip install uv or brew install uv are alternatives.
• After installing, the first uvx run downloads the server package. Give it a minute on slow networks.

The official @modelcontextprotocol/server-sqlite is installed and run via uvx (uv run --with mcp-server-sqlite), which requires the uv package manager from Astral. The spawn uvx ENOENT failure is the standard symptom when uv is not installed or not on PATH, and the documented fix is installing uv from https://docs.astral.sh/uv/ before configuring the server. This matches the widely reported setup failure for uvx-based MCP servers.

Not specified by the original author.

TL;DR

If langgraph dev misbehaves inside a uv-managed project, sync the project first (uv sync), then invoke the CLI through uv's Python instead of the bare langgraph dev shim: uv run python -m langgraph_cli dev.

Steps

1. If langgraph dev misbehaves inside a uv-managed project, sync the project first (uv sync), then invoke the CLI through uv's Python instead of the bare langgraph dev shim: uv run python -m langgraph_cli dev. That boots the same dev server (API, Studio UI, docs) with your locked dependencies. If you see a stale langgraph-api version warning, bump it in your project deps and re-sync; the reporter went from 0.4.28 to 0.5.x this way.
2. Source: https://github.com/langchain-ai/langgraph/issues/5463 (LangGraph)

When to use

You are seeing this: That boots the same dev server (API, Studio UI, docs) with your locked dependencies. Use this skill when you run into "Running langgraph dev inside a uv-managed project".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

Versions mentioned in the source: 0.4.28. If you are on something much newer or older, the details may have shifted.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Sources

• https://github.com/langchain-ai/langgraph/issues/5463

In gh:langchain-ai/langgraph#5463, the issue was: Support uv with langgraph dev. langgraph.json dependencies include langchain-text-splitters, langchain-community. Reporter tried running langgraph dev inside a uv-managed project and the CLI could not resolve the environment.. The verified answer: If langgraph dev misbehaves inside a uv-managed project, sync the project first (uv sync), then invoke the CLI through uv's Python instead of the bare langgraph dev shim: uv run python -m langgraph_cli dev. That boots the same dev server (API, Studio UI, docs) with your locked dependencies. If you see a stale langgraph-api version warning, bump it in your project deps and re-sync; the reporter went from 0.4.28 to 0.5.x this way.. Issue URL: https://github.com/langchain-ai/langgraph/issues/5463

Not specified by the original author.

TL;DR: ~ in --db-path does not mean your home directory to the SQLite MCP server. Tilde expansion is a shell feature and the server is launched without a shell, so it looks for a literal directory named ~ and fails. Write out the full path.

Error: unable to open database file

(With --db-path set to something like ~/data/app.db.)

Fix it

1. In your MCP client config, replace the tilde with the real home directory:

{
  "args": ["mcp-server-sqlite", "--db-path", "[HOME]/..."]
}

Find your home directory with echo $HOME in a terminal.

2. Restart the MCP client.

   Expected: the server opens the database and tools work.

When to use this

• --db-path contains ~ and the server cannot open the file.
• The same path works when pasted into a terminal (because your shell expands the tilde there).

When NOT to use this

• The path has no tilde and still fails. Then it is a permissions or missing-directory problem.
• The error is no such table. The file opened; it is just the wrong or an empty one.

Compatibility

• @modelcontextprotocol/server-sqlite.
• All MCP clients, since none of them run a shell to expand the argument.

Why it happens

When you type ~/data/app.db in a terminal, your shell rewrites it to [HOME]/... before the program ever sees it. MCP clients spawn servers directly via process APIs, with no shell in between, so the server receives the literal two-character string ~/... and treats it as a relative path. There is no ~ directory, so the open fails.

Edge cases

• Environment variables like $HOME in args are not expanded either, for the same reason. Some clients support ${HOME} in the env block, but not in args.
• On Windows, %USERPROFILE% is not expanded in args either. Use the full C:[HOME]/... path.
• If you generate configs with a script, expand the path in the script before writing the JSON.

The @modelcontextprotocol/server-sqlite takes --db-path as a literal argument and does not expand ~ (tilde expansion is a shell feature, and MCP clients spawn the server directly without a shell). Users configuring --db-path as ~/data/app.db get unable to open database file because the server looks for a directory literally named ~. The fix is using the absolute path with the home directory written out. This is the same class of issue as the documented absolute-path requirement for Claude Desktop configurations.