API

[chad-orases]

Hi - does your mcp server allow interaction with the n8n api on self hosted n8n instances?

[chad-orases]

I'm trying to install this mcp to use in my claude code terminal but it will not connect due to this issue:
The n8n-mcp server is failing during database health check because it's missing the FTS5 (Full Text Search 5)
module in sql.js. The server falls back to sql.js but encounters an error during the health check.

[czlonkowski]

Hey @chad-orases — answering both of your messages in one go.

On the original question (does n8n-mcp work with self-hosted n8n): Yes, fully. Self-hosted is actually the most common deployment. You set two env vars:

N8N_API_URL=https://your-n8n-instance.example.com
N8N_API_KEY=<generate in n8n: Settings → API>

No /api/v1 suffix on the URL — the client adds it. After that, all the n8n_* management tools (create/update/validate workflows, executions, credentials) work against your instance the same as they do against cloud.

On the FTS5 / sql.js issue. What you are seeing is the database adapter falling back from the native better-sqlite3 to the WASM sql.js. The WASM build does not ship with FTS5 compiled in, so the full-text search table exists in the schema but cannot be queried, and downstream code crashes when search runs.

The root cause is almost always one of two things:

1. Node version mismatch — better-sqlite3 ships precompiled binaries for specific Node ABI versions. If you are on a Node version that does not have a prebuilt binary (e.g., very new or very old), the install silently falls back to sql.js. Fix:

   npm rebuild better-sqlite3

   or, cleaner:

   rm -rf node_modules package-lock.json && npm install

   Make sure you have build tools available (python3, make, a C++ compiler — xcode-select --install on macOS, build-essential on Debian/Ubuntu, apk add python3 make g++ on Alpine).

2. You are on an unusual platform where no prebuilt binary exists. In that case, just use the Docker image — it bakes better-sqlite3 in at build time and ships a pre-built database, so you skip all the native-build pain:

   docker run -i --rm \
     -e N8N_API_URL=https://your-n8n.example.com \
     -e N8N_API_KEY=your-key \
     ghcr.io/czlonkowski/n8n-mcp:latest

   Point Claude Code at it via your MCP config the same as any other docker-based MCP.

Either path will get you off sql.js and onto the native adapter, and the FTS5 crash will go away.

Also worth noting: the health check itself only warns about a missing FTS5 table — the actual crash you are hitting is downstream when a search query tries to use it. I will look at making that fail more gracefully so future users get a clearer error message instead of "health check failed". Thanks for reporting it.