FeatureQL with AI

FeatureQL is typed, named, and composable — a safer surface for an LLM than raw SQL. This page is how to put that in an assistant's hands: three setups, from a quick sandbox install to a shared team registry.

There is no managed MCP and no managed execution of your queries. The MCP server and the SQL engine always run where you control them. FeatureMesh never sees your row data.

1. Pip library in the assistant's sandbox

Fastest path when the LLM can install packages (Cursor, Claude Code, hosted sandboxes, notebooks).

Ask it to install FeatureMesh next to DuckDB for batch work:

pip install featuremesh duckdb
bash

Or with the serving extra when you also want the embedded real-time path:

pip install "featuremesh[serving]"
bash

Then a local BatchClient is enough — no account, no server:

from featuremesh import BatchClient

client = BatchClient()
result = client.query("SELECT F := 1;")
print(result.dataframe)
python

Persistence is whatever that process keeps (often ephemeral). The sandbox also does not reach your internal warehouse — only what you put in that isolated environment. Fine for learning and one-off queries; less fine if you need real company data or features that survive across chats.

Details: Python library .

2. Local MCP + embedded registry (persist across sessions)

When you want the assistant to keep working on the same features and data day after day, run MCP on your machine against an embedded registry (local SQLite). Typical setup: a container (or the demos stack) that exposes MCP locally, with the registry file on disk.

Your AI client connects to that local MCP endpoint. Whatever the MCP can reach — including your internal data warehouse, if you wired the SQL executor to it — the LLM can query through FeatureQL. Features you CREATE, loaded tables, and help lookups stick around between sessions. Unlike the sandbox in (1), this is how you give an assistant access to real internal data without uploading it anywhere.

Use this when:

  • One person (or one machine) owns the project
  • You care about continuity more than sharing a registry with colleagues
  • You want the model on your warehouse, not only on sandbox sample data
  • You want zero cloud account for the registry itself

3. Local MCP + managed registry (collaborate)

When several people should share the same feature definitions, point the same local MCP at the managed FeatureMesh registry. Registration is free; you need an API key (access token) from console.featuremesh.com .

What is managed: feature definitions, namespaces, and access control — the catalog your team shares.

What stays local: MCP, and execution of SQL against your DuckDB / warehouse / on-prem serving. Your data does not leave your environment for FeatureMesh to run.

Use this when you want a shared, versioned feature graph without standing up a shared SQLite file.

Giving the model good FeatureQL context

Do not paste the whole documentation site into a prompt. Prefer the LLM help corpus:

With a client or MCP connected, the same pages come back from help('tag') / featuremesh_help. For a simple validate → diagnose → query loop, see Working with an assistant . To run the documentation suite on your backends, see Conformance tests .

Next steps

Last update at: 2026/08/04 11:25:38