Skip to main content
An empty workspace is a blank canvas with a query planner hiding behind it.
This tutorial exposes one HeavenBase workspace as a live MCP server. The agent can define entities, write rows, inspect schemas, and query data without you writing a transport layer or CRUD wrapper. This surface differs from a registered Toolkit. workspace.serve(...) closes over one live workspace object and remains available only while that process runs. Registered Toolkits persist their callable Capsules as workspace rows and can be loaded later by reference.

1. Motivation

Giving an agent a database password exposes storage without explaining the domain. Writing a custom MCP server explains the domain, but often duplicates schema validation, routing, query parsing, and serialization. HeavenBase exposes the workspace it already owns:
The profile limits the model-facing surface while every tool still uses the same entities, Catalog, MetaSchema, routing plan, and backend authority as Python code.

2. Create and Serve an Empty Workspace

Create serve_space.py:
Run it:
The debug preset gives the tutorial a local SQLite-backed workspace without requiring Docker. Re-running the script reopens the registered workspace and keeps its data.
Do not put workspace.drop() in the server script unless every start should destroy the workspace. Stop the server first, then drop the workspace explicitly when you truly want to remove its owned data.
The server listens at http://127.0.0.1:7001/mcp. Keep this process running while external clients use the tools.

3. Understand the Live Boundary

workspace.to_mcp(...), workspace.to_mcp_json(...), and workspace.serve(...) create a runtime-only Toolkit that closes over the current workspace object. That Toolkit cannot be registered as a durable Capsule Toolkit because its functions depend on live workspace and backend objects. Persisted state still survives in the workspace; the MCP transport itself does not. Use First MCP when you need durable callable tools. Use this page when you want agents to operate on one live application workspace.

4. Choose an Explicit Profile

The profile is an allowlisted MCP surface, not a request to enable every extension. The tutorial uses agent. It omits bulk mutation, existence checks, and deletes while retaining the tools needed for first-day schema and data work. Enable optional roots before selecting their profiles:
Enabling memory does not silently enable database, and choosing profile="database" does not install the database extension for you. The workspace manifest records the roots you explicitly selected.

5. Connect a Client

Configure the running Streamable HTTP endpoint in one client.
Add and verify the server:
Start a new session and run /mcp before asking the agent to use the workspace.
The JSON printed by workspace.to_mcp_json(...) is a portable starting point for clients that use the common mcpServers shape.

6. Try a Small Store

Send these prompts in order.
1

Define the model

2

Add data

3

Ask a question

The agent defines schema through MetaSchema, writes concrete rows, discovers them through Catalog-aware tools, and queries them through the same routing system used by Python callers.

Summary

  • Workspace MCP closes over one live workspace and must be served by a running process.
  • Workspace data persists independently from that transport process.
  • Profiles expose deliberate tool sets; optional profiles require their extensions first.
  • Registered Capsule Toolkits are a different persistence mechanism with explicit workspace ownership.

Further Exploration

Related resources: