> ## Documentation Index
> Fetch the complete documentation index at: https://docs.metabind.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Metabind CLI

> Build, validate, publish, and operate Metabind MCP apps from the terminal

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

<CardGroup cols={2}>
  <Card title="Install and Sign In" icon="rocket" href="/cli/install">
    Install the binary, authenticate, and connect it to a project.
  </Card>

  <Card title="Context Resolution" icon="layer-group" href="/cli/context">
    Understand how project scope, auth, and config interact.
  </Card>

  <Card title="Workflow Map" icon="list-tree" href="/cli/verbs">
    See how setup, inspection, authoring, release, and operations fit together.
  </Card>

  <Card title="Workflow Patterns" icon="list-checks" href="/cli/workflows">
    Build, publish, rollback, secret, and MCP host handoff loops.
  </Card>
</CardGroup>
