For agents — CLI + MCP

Agents are first-class operators of a Cowliss org. Everything the dashboard can do, an agent can do — through the cow CLI, through the MCP server, or directly against the typed REST API. All three are the same surface: the CLI and MCP server are thin clients of the API, so parity is structural rather than maintained.

The CLI

cow login          # browser flow; caches a session token at ~/.cow/credentials.json
cow apps list      # every command prints the response envelope as JSON

Non-interactive and agent-friendly by design:

--json forces compact single-line output; piping (non-TTY) does the same automatically.
Commands that take JSON arguments accept - to read the document from stdin.
--api <url> overrides the API base URL; cow login --no-open prints the login URL instead of opening a browser, for headless environments.
Errors exit non-zero with the API’s error envelope on stderr.

The full surface (auth, apps and their sources, catalog and governance, violations, segments, destinations, sending domains, suppressions, billing, journeys with their stats, dry-run and enable toggle, releases, deployments, executions, deliveries, and users, plus the local project commands init, build, test, add example, push, deploy, rollback, pull, and dev) is in the CLI reference, generated from the command definitions themselves.

The project commands are what an agent uses to write a journey: cow init, then edit journeys/ and emails/, then cow test for a scenario on a virtual clock and cow deploy --env development to run it for real. All of it is files and exit codes, no browser involved. See Projects.

The MCP server

The same admin API exposed as native tools for in-editor agents. Tool names are the API’s operation ids with underscores (apps_list, apps_sources_add, segments_create, journeys_dryRun, …) and are stable per major.

{
  "mcpServers": {
    "cow": {
      "command": "node",
      "args": ["--import", "tsx", "apps/mcp/src/index.ts"],
      "env": { "COW_API_URL": "http://localhost:3400" }
    }
  }
}

The server reads the CLI’s cached credentials (~/.cow/credentials.json), re-reading on every call so a fresh cow login is picked up without restarting the editor session — or set COW_TOKEN explicitly. Role gates apply identically: an agent with a member token gets exactly what a member clicking the dashboard gets.

Docs an agent can read

These docs are published machine-readable alongside the human pages:

/llms.txt — the site map: every page with a one-line summary and a link to its markdown.
Per-page markdown — append index.md to any page URL, e.g. /journeys/index.md.
/llms-full.txt — the entire docs site as one markdown document, for stuffing a context window.
/openapi.json — the OpenAPI 3.1 document for the whole API, generated from the same zod schemas the server validates with. Prefer it over scraping HTML when calling the API directly.

Simulator and dry-run for agents

Two surfaces matter most when an agent iterates on journeys: cow test runs a scenario file in seconds (the scenario JSON schema is deliberately small, being a user, later events at offsets, and expected side effects, so it is meant to be written by hand or by an agent), and cow journeys dryRun validates against real state with sends disabled. Both are covered in Testing journeys.