Having `run_read_query` beside `run_query` is what makes this comfortable to hand to an assistant: exploration goes through the read tool, and writes need the tool that says so. The schema tools are the other half of that — labels, relationship types, indexes and constraints let a model compose a query against the graph as it actually is rather than as it assumes.
An MCP server for Neo4j over stdio. It splits the surface into three parts: running Cypher, inspecting the graph's schema, and reading server information — so an assistant can find its way around a graph before querying it.
- Cypher execution with the read path kept separate — `run_query` and `run_read_query`
- Schema inspection: the schema itself, node labels and relationship types — `get_schema`, `get_labels`, `get_relationship_types`
- The metadata that decides whether a query will be fast — `get_indexes`, `get_constraints`
- The server's address and version — `get_server_info`
- An install with no build step — `bunx @daanrongen/neo4j-mcp`
- A local inspector run — `bun run build && bun run inspect` — that lists every tool and shows request and response shapes
A reachable Neo4j instance and two environment variables: `NEO4J_URL`, a Bolt URL such as `bolt://localhost:7687` or `neo4j://localhost:7687`, and `NEO4J_PASSWORD`, with the username defaulting to `neo4j`. Bun on the machine to run `bunx`; the documented setups are a Claude Desktop stdio entry and a one-line `claude mcp add` for the CLI. The package is `@daanrongen/neo4j-mcp` 1.1.4.
One command plus a key — bunx @daanrongen/neo4j-mcp, then supply credentials