MCP is the doorway; the Toolkit decides which rooms have handles.
1. Motivation
A runtime Toolkit can wrap live objects, workspace closures, or a remote FastMCP server. Those values can serve tools now but cannot always be restored later. A persisted Toolkit must reference durable Capsules and belong to one explicit application workspace. HeavenBase therefore keeps construction, persistence, profile assembly, and transport as separate operations. The sameTool contract crosses them, while each boundary stays inspectable.
2. Use the Tool API
Tool.annotations, separately from arbitrary Tool.metadata. Use the official wire names: title, readOnlyHint, destructiveHint, idempotentHint, and openWorldHint.
3. Use the Capsule API
include_cloudpickle defaults to False. Restore and execution are trusted-code operations even when fingerprint verification succeeds.
4. Use the Toolkit API
ws= from Toolkit persistence calls uses existing-only hb.HeavenBase.load(). It never creates a workspace.
5. Understand Workspace-Owned Rows
Capsule is the required Extension root. Toolkit is a packaged default root.
Toolkit.register(ws=...) ensures the workspace owns both Toolkit and referenced Capsule rows.
Standalone Capsule.register() uses an advanced Context-private hidden store for machine/domain administration. Do not confuse that store with application Toolkit persistence.
6. Use Workspace MCP Tools
workspace.to_mcp(profile=...) and workspace.serve(profile=...) assemble Registry-backed Toolkit families. Backend inspection tools project their existing read_only contract to MCP readOnlyHint. The core workspace family includes:
There are no generic
alter_entity or undefine_entity MCP tools. Entity migration, physical cleanup, Catalog changes, and recovery require explicit domain policy before they are safe for agents.
7. Select a Profile
Profiles aremcp_profile Registry records. They compose exact tool names, Toolkit families, Entity and Skill scopes, one serializer, dependencies, and optional extends.
External modules may publish their own Toolkit families and profiles through
meta.yaml. The owning Context resolves them before workspace assembly; optional families activate only through declared workspace_requires.
8. Use the MCP CLI
All Toolkit commands accept or resolve an existing workspace:REF accepts Toolkit id, name, or namespace/name:version.
9. Serve and Verify
heavenbase.mcp. Keep unauthenticated HTTP on loopback. Use stdio for local coding-agent integrations when a long-lived network server is unnecessary.
10. Export Anthropic Programmatic Tools
allowed_callers, name, description, and input schema. Execution adapters should return strings when called from code execution.
11. Apply the Trust Checklist
- Review Capsule source, layers, schemas, and serializer.
- Keep binary fallback disabled unless reviewed local code needs it.
- Persist concrete Toolkits in an explicit application workspace.
- Use the smallest profile that supports the task.
- Namespace external tools and reject collisions.
- Treat Tool annotations as hints, never as an authorization decision.
- Validate untrusted arguments at the Tool or owning API boundary.
- Keep filesystem, credential, network, and destructive authority explicit.
- Test real list/call behavior through the intended transport.
Summary
- Tool, Capsule, and Toolkit APIs share one callable execution model.
- Persisted Toolkits and Capsules belong to an explicit application workspace.
- Official MCP annotations and structured results round-trip through FastMCP 4.
- Profiles, serializers, and transport configuration keep MCP authority inspectable.

