Metabind CLI

The Metabind CLI is the scriptable control plane for cloud Metabind projects. Use it to validate BindJS modules before they are saved, create and update components, publish package versions, move runtime pins, and create credentials for MCP hosts. The same commands work in an interactive terminal, a script, or a coding-tool run: inspect current state, make a narrow change, validate it, publish it, probe the runtime result, and hand off concrete IDs and runtime URLs. The CLI makes project work observable and repeatable: each loop starts from known project state, validates source before it is saved, and ends with evidence from the published runtime.

​

Project Model

• Projects are the cloud workspace for an MCP app.
• Components store BindJS modules in a project.
• Tools are the MCP-facing surfaces backed by project components.
• Content stores structured rows that tools can render or operate on.
• Draft state is the editable project state before release.
• Packages are published snapshots of the project.
• Pins select the package version a tool serves at runtime.
• Project API keys let MCP hosts connect to a project endpoint.

​

Typical Flow

1. Sign in and choose a project context.
2. Inspect current project state.
3. Pull the BindJS reference needed for the task.
4. Author or update a component or data-source module.
5. Validate the module before saving it to the project.
6. Create or update project objects.
7. Publish when the draft state is ready.
8. Probe the published tool with representative input.
9. Roll back, upgrade, or intentionally leave the project in its current state.
10. Report the final project state and the surface to test.

​

Authoring Model

BindJS modules are the authoring unit for component source. A module with a default defineComponent export defines UI behavior. A module with a default defineDataSource export defines server-side data behavior. The CLI validates module source before it saves that source to a project component. The installed CLI includes the BindJS reference, so command-driven workflows can read the relevant API surface before writing source.

​

Release Model

Publishing freezes draft state into a package version and updates the runtime pins for changed tools. Rollback and upgrade move pins between published packages; rollback can also materialize the target component versions and publish them as the next package when that is the desired outcome. That model keeps release work explicit:

• Draft edits can be validated before release.
• Published packages remain available after tools move away from them.
• Rollback can restore runtime behavior without deleting later work.
• Upgrade can move stale pins forward when the project should return to the latest package.
• Rollback with persistence restores target source before publishing, so the new package carries the rolled-back behavior.

​

Start Here