Pixeltable Developer
io.github.pixeltablev0.2.1Updated Oct 11, 2026
Pixeltable MCP server for declarative multimodal tables, computed columns, and services.
Overview
Lets an assistant scaffold, inspect, and operate local Pixeltable applications: tables, computed columns, rows, and services.
- What it does
- A local stdio server that wraps the pxt CLI so an assistant can scaffold an app.py, apply its tables to a catalog, insert and inspect rows, recover failed computations, and manage HTTP service routes. Tools cover catalog inspection, row data, app scaffolding, schema lifecycle (check, diff, update, prune), and service lifecycle (check, diff, update, list, stop, prune). Read tools are read-only; mutation tools declare write and destructive behavior, and prune tools default to dry runs. It also exposes status and catalog resources plus build and debug prompts.
- When to use it
- Use it when you are developing or operating a Pixeltable application locally and want an assistant to edit app.py, evolve table schemas, load or inspect rows, and start or stop services. It is a beta developer tool, so it suits trusted local development rather than production administration.
- Requirements
- Local process run with uvx from PyPI; Python 3.11 or newer and Pixeltable >=0.7.10,<0.8 with the serve extra. Requires PIXELTABLE_MCP_PROJECT_ROOT (directory holding app.py, which must exist) and PIXELTABLE_HOME (catalog directory). Optional: PXT_PORT (default 22089), PIXELTABLE_MCP_PXT, PIXELTABLE_MCP_ENABLE_UNSAFE. Restart the client after changing configuration.
Installation
In SourceWeft
- Open Pixeltable Developer in the dashboard and add it to a workspace.
- Enable the server for the chats that should use its tools.
Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.
Other MCP clients
Follow the launch instructions in the repository.
README
Pixeltable Developer MCP Server
A local MCP server for building and operating Pixeltable
applications. Through the pxt CLI, an agent scaffolds one app.py, applies its
tables to a catalog, inserts and inspects rows, recovers failed computations, and
serves HTTP routes. It is a beta developer tool: it runs with your permissions and
changes the catalog you point it at.
Quick start
Install uv. The server is on
PyPI, and uvx downloads and runs it.
Claude Code:
Other clients (Claude Desktop, Cursor, VS Code, and so on):
The app directory must exist. An empty one is fine: the server can scaffold app.py
there. Restart the client after changing its configuration.
Both paths are fixed for the life of the process. Run one server per catalog when it applies schema or service changes.
Other ways to run it
Docker: mount the app directory, and keep the catalog in a named volume so it persists.
Do not bind-mount a catalog from a macOS host: Postgres cannot set permissions on that
directory, and initdb fails. On macOS, the app path must also be shared with your
container engine, or the mount lands inside its VM.
What the server exposes
Read tools carry read-only annotations; mutation tools declare write and destructive behavior. Prune tools default to dry runs. Failures come back as MCP tool errors, so a client can retry with corrected input.
Prompts: pixeltable_build_app, pixeltable_build_rag, pixeltable_build_agent, and
pixeltable_debug_computation. They follow
pixeltable-skill 2.12.0,
which stays the detailed reference for providers, multimodal views, indexes, tool
calling, and serving.
Pixeltable workflow
These are the commands the tools wrap:
my_appis a catalog directory, not a folder on disk.pxt service listshows the assigned URL.- In
app.py, stored columns are annotations and computed columns are assignments. Types are non-nullable; writeT | Nonefor an optional column. Do not usepxt.Required. - To change a computed expression, edit it and update the schema. The update keeps
existing values, so run
pxt recompute my_app/docs COLUMN -fto refresh them. A type change is unsupported in place; rename the computed column instead. - Cloud uses the same
app.py:pxt login, a[[pixeltable.database]]entry inpixeltable.toml, and provider keys throughpxt secret set, never in the TOML.pixeltable://guidance/cloudlists the order. The server creates no paid resources.
Unsafe mode
PIXELTABLE_MCP_ENABLE_UNSAFE=1 adds pixeltable_unsafe_execute_python,
pixeltable_unsafe_install_package, and pixeltable_unsafe_display. They run arbitrary
Python, change the server's environment, read any file the process can, and render
untrusted content in a browser canvas. They exist only over stdio: enable them for a
trusted local client in a disposable environment. HTTP is not a supported transport.
Compatibility
Releases
CHANGELOG.md lists what each version changed. 0.2.1 is the first PyPI release.
To ship a version:
- Bump the version in
pyproject.toml,src/mcp_server_pixeltable_developer/__init__.py,server.json(twice),mcpb/manifest.json,plugin/.claude-plugin/plugin.json(version anduvxpin), and the assertions in.github/workflows/ci.ymland the tests. Add a## X.Y.Zsection toCHANGELOG.mdand runuv lock. The tests fail until every copy agrees. - Merge, then push the tag
vX.Y.Z. CI reruns every check, publishes to PyPI with trusted publishing, creates the GitHub Release from the changelog section, then publishesserver.jsonto the MCP Registry with GitHub OIDC. - If the registry step fails, rerun it without a new tag:
gh workflow run mcp-registry.yml --repo pixeltable/mcp-server-pixeltable-developer --ref main.
Glama syncs from GitHub. The Docker MCP Catalog entry (servers/pixeltable/server.yaml
in docker/mcp-registry) pins a commit, so it needs a PR per release.
Develop and verify
--run-slow runs real catalogs and services in temporary directories, each on its own
daemon port. build-mcpb.sh writes the Claude Desktop bundle to dist/. For manual
testing, run the MCP Inspector against the server:
uv run mcp dev src/mcp_server_pixeltable_developer/server.py:mcp.
Privacy Policy
The server runs entirely on the machine that starts it. It collects no telemetry and no analytics, and it sends nothing to Pixeltable or to any third party.
What it handles. The Pixeltable catalog at PIXELTABLE_HOME and the
application files under PIXELTABLE_MCP_PROJECT_ROOT, both chosen by you. Tool
results are returned to the MCP client that launched the server, which is how
your assistant reads them. Nothing else receives them.
Storage and retention. The server stores nothing of its own. Catalog data
stays in PIXELTABLE_HOME on your disk, under your control, and is removed when
you remove it.
Secrets. Command output is passed through a redactor that masks common credential forms, including URL passwords and API tokens, before it reaches the client.
Third parties. If your application declares computed columns that call model providers, Pixeltable makes those calls with the credentials you configured. That traffic is your application's, not this server's.
Unsafe mode. With PIXELTABLE_MCP_ENABLE_UNSAFE=1, the added tools execute
arbitrary Python, install packages, and read files available to the server
process. Enable it only on a trusted local machine.
Contact. Report privacy questions through GitHub issues.
Documentation
- Changelog
- Migration from 0.1 to 0.2
- 0.2.0 implementation review and 0.1.0 evidence review
- Agent evaluation protocol
- Pixeltable documentation and LLM reference
- MCP Python SDK 2 documentation
License
Apache-2.0. See LICENSE.
Source: README.md at commit f514e51
Tools
0Version history
1- v0.2.1LatestOct 11, 2026


