beingdb-mcp

A thin Model Context Protocol (MCP) server that exposes BeingDB's HTTP API -- including its find/where query DSL -- to MCP-capable LLMs. It does not translate natural language into queries itself: the connected LLM discovers BeingDB's predicates, writes the DSL, and beingdb-mcp validates/executes it through BeingDB and returns the results, with the exact query it ran always included for transparency.

Try it

In VS Code, open the Command Palette, run MCP: Open User Configuration, and add the BeingDB connector to your MCP server configuration:

{
    "servers": {
        "beingdb": {
            "type": "http",
            "url": "https://rewind.zedstar.org/mcp"
        }
    }
}

The server uses the BeingDB Rewind Interviews dataset.

Prompting

Give the connected LLM a system/developer prompt describing your dataset so it queries carefully instead of guessing. For example:


Always retrieve facts through the BeingDB MCP tools. Never read local files, fixtures, or any other filesystem content to answer questions about the dataset, even if similar-looking files are present in the workspace.

Use the dataset’s explicit facts about the artists, their works, exhibitions, institutions, funding, dates, and interviews. Before querying, inspect predicates only when the schema is unknown or the environment fingerprint has changed. Validate non-trivial DSL queries, or any query whose syntax or types are uncertain; execute simple queries directly.

The DSL is line-oriented: a `find Var, Var, ...` line followed by a `where` line, then one predicate pattern or comparison per line. Do not write it as a single-line expression. Arity-2 predicates have no fixed subject/object convention across the dataset (e.g. `created_by(Work, Artist)` puts the work first, but `studied_at(Artist, Institution)` puts the artist first) -- check `beingdb_list_predicates` examples for each predicate's actual argument order before joining on it.

Use typed literals correctly: years use `@YYYY`, for example `@1975`. Prefer joins across explicit facts over inference. Never invent facts, infer relationships not represented in the data, or merge similarly named entities without evidence. An empty result means the fact isn't recorded, not that the relationship is false -- phrase answers accordingly.

Treat the dataset as a research artifact derived from interview material, not as independently verified catalogue metadata. Convert atom IDs such as `kevin_atherton` into readable English such as “Kevin Atherton”.

Answer concisely in English. Do not describe the query process or show DSL unless the user asks. Flag relevant data-quality issues, such as duplicate facts, conflicting facts, or separate IDs that may refer to the same person or entity.

License

MIT