Skip to main content
The AgentMark CLI (@agentmark-ai/cli) provides tools for developing, testing, and building your AI prompts.

Commands at a glance

Jump to any command’s full reference:

Installation

In a project scaffolded by agentmark init, @agentmark-ai/cli is also pinned as a local dev dependency, so npm run dev and CI resolve that pinned version from node_modules/.bin regardless of what’s installed globally.

Environment variables

The CLI automatically loads environment variables from a .env file in the current working directory. This happens before any command execution, so you can store API keys and configuration there.
See Environment variables for the full list.

Update notifications

The CLI checks for updates asynchronously when you run commands. If a newer version is available, you’ll see a notification after your command completes. This check is non-blocking. To disable update checks, set the environment variable:

Commands

agentmark init

Set up AgentMark in a new or existing project. Writes agentmark.json, creates the agentmark/ prompts directory, pins @agentmark-ai/cli as a local dev dependency (plus npm scripts), wires IDE MCP configs for the clients you pick, and installs the agent skill. Run it once per project: from inside an existing repo (the common case) or with a folder name to scaffold a fresh one.
Options: The local pin is non-destructive: an existing dev / build script is never overwritten. AgentMark’s scripts land under namespaced keys (agentmark:dev, …) instead. npm create agentmark is a thin wrapper that runs this exact flow.

agentmark doctor

Check that you set up your AgentMark project correctly. The default pass is a static health check (no network calls, no servers spawned) that inspects your config, prompts, client, and dependencies and reports each finding with a fix. The optional --smoke tier adds a live end-to-end run. Run it right after scaffolding, or when a command fails with a config or dependency error.
Options: What it checks:
  • Project: agentmark.json is present and valid (including field/schema shape: required keys present, no unknown-key typos); agentmarkPath resolves (catches the "/" mistake); the client file (agentmark.client.ts / agentmark_client.py), the dev-server entry, and the managed-deploy handler (handler.ts / handler.py) exist; AGENTMARK_API_KEY / AGENTMARK_APP_ID are present; .env is gitignored; Node.js is 20.6+.
  • Config & prompts: every .prompt.mdx parses and declares a model_name; you declare prompt models in builtInModels (doctor enforces a non-empty list as an allowlist); the catalog recognizes the models.
  • Dependencies: doctor checks that you installed the runtime packages (resolvable from the project), not just listed them in package.json. The client and dev-entry import @agentmark-ai/prompt-core, so doctor fails the check when package.json declares prompt-core but node_modules lacks it, and points you to npm install; a missing install is the most common reason agentmark dev or doctor --smoke --boot exits 1. @agentmark-ai/sdk carries tracing and the cloud-execution runner; doctor warns (rather than fails) when node_modules lacks it or package.json omits it. agentmark init pins @agentmark-ai/cli locally so CI and teammates run the same version; a missing pin is an advisory warning. For Python projects, doctor checks that agentmark-prompt-core and agentmark-sdk import, and skips with a reminder when it can’t verify them. There is no SDK-specific adapter to require: you bring your own SDK through @agentmark-ai/prompt-core’s neutral render or an executor.
  • Live run (--smoke): runs one prompt end-to-end through agentmark dev and confirms real output + token usage came back, then fetches the emitted trace and validates its shape, exercising your SDK, provider keys, and tracing indirectly, with no provider-specific knowledge.
Exit code: 0 when nothing failed (warnings don’t fail the run), 1 on any failure, or on any non-advisory warning with --strict. Advisory warnings (like a missing local @agentmark-ai/cli pin) are informational and never fail the run, so adding agentmark init to an existing project won’t turn a green --strict CI gate red. So it drops straight into CI. Example:
For the failures it surfaces, see Troubleshooting.

agentmark dev

Start the local development environment: the API server, the webhook server, and the local dev UI app. Once you link the project (agentmark link), traces from local runs automatically forward to AgentMark Cloud.
Options:
For programmatic Cloud access, run the agentmark-mcp MCP server or call the gateway REST API directly.
Project detection:
  • TypeScript projects: agentmark.client.ts in the project root
  • Python projects: pyproject.toml, agentmark_client.py, or .agentmark/dev_server.py
Dev server entry points (TypeScript): The CLI looks for dev server files in this order:
  1. dev-server.ts (custom override, project root)
  2. dev-entry.ts (default location, project root)
Python virtual environment: For Python projects, the CLI auto-detects .venv/ or venv/ directories. Example:

agentmark login

Authenticate with AgentMark Cloud via browser OAuth. The CLI opens your default browser to complete the login flow, then stores credentials locally for subsequent commands.
Options: agentmark link, trace forwarding in agentmark dev, and the agentmark-mcp MCP server all use the stored credentials automatically. For the MCP server, the AGENTMARK_API_KEY environment variable takes precedence over the cached session bearer; agentmark link itself always requires a login session.

agentmark logout

Clear stored CLI authentication credentials.
Options:
Link your local project to an app in AgentMark Cloud. The CLI prompts you to select an app from your account (or use --app-id to skip the prompt), then stores the app ID and app/org metadata in .agentmark/dev-config.json. The CLI creates no API key: trace forwarding authenticates with your login session.
Options: After linking, agentmark dev automatically forwards traces from local prompt runs to the linked app, with no flag needed. agentmark dev reads the linked appId from .agentmark/dev-config.json (per-developer, gitignored). The forwarder authenticates with the session bearer from ~/.agentmark/auth.json (auto-refreshed).

agentmark run-prompt

Run a single prompt file with test props.
Arguments: Options: Example:

agentmark run-experiment

Run an experiment against its dataset, with evaluations by default.
Arguments: Options: Example:

agentmark generate-types

Generate TypeScript type definitions from your prompt schemas.
Options: Output: The command outputs TypeScript definitions to stdout. Redirect to a file:
Generated types include:
  • Input types based on input_schema
  • Output types based on the model’s schema
  • A mapping of prompt paths to their respective types
  • Tool argument types
Example:
See Type safety for usage examples.

agentmark generate-schema

Generate a JSON Schema file for .prompt.mdx frontmatter. This enables IDE validation (squiggles) for fields like model_name in your prompt files.
Options: Example:

agentmark build

Build prompts into pre-compiled JSON files for static loading with FileLoader.
Options: Requirements:
  • An agentmark.json config file must exist in the current directory
  • agentmark build reads prompts from the directory that agentmarkPath names in the config
Output structure:
Example:
See Loaders for using built prompts with FileLoader.

agentmark pull-models

Pull and configure models from a provider. Runs interactively by default; pass --provider + --models to skip the prompts (for example, for CI or agents).
Options: With both --provider and --models set, the command runs fully non-interactively and is safe for CI. This command opens an interactive prompt (when you pass no flags) to:
  1. Select a model provider
  2. Choose models to enable
  3. Update your local configuration
Agent / CI discovery workflow Use --list to discover valid providers and model IDs before modifying config (no agentmark.json required):
--list output is stable JSON, safe to pipe into jq or capture in scripts.

Programmatic gateway access (for agents and scripts)

Programmatic gateway access is available through two protocol-level surfaces that stay in lock-step with the gateway’s OpenAPI spec:
  • IDE agents (Claude Code, Cursor, VS Code, Zed): run the agentmark-mcp MCP server. It fetches the gateway’s OpenAPI spec at startup and exposes one MCP tool per operation (for example create_app, list_traces, start_app_git_connect). The agent calls those tools directly; no CLI invocation needed.
  • CI / shell scripts: call the gateway REST API with curl and an AGENTMARK_API_KEY. AgentMark generates the MCP tools from the same OpenAPI spec, so request shapes are identical; only the transport differs.
Both targets honor the same auth chain: AGENTMARK_API_KEY env var first, then the session bearer from ~/.agentmark/auth.json (written by agentmark login).

Configuration files

agentmark.json

Project configuration file in your project root. See Project config for the full schema.

.agentmark/dev-config.json

Auto-generated local development configuration (gitignored):
This file stores:
  • appPort: local dev server UI port (updated when dev server starts).
  • forwarding: linked app metadata (app ID, app and org names, gateway base URL) used by agentmark dev when forwarding traces to AgentMark Cloud. Populated by agentmark link and cleared by agentmark logout. No credentials live here: the forwarder authenticates with your login session.
The configuration expires 30 days after creation: the next CLI command that loads it regenerates a fresh file, and running agentmark link again restores the app binding.

Have questions?

Reach out any time: