For AI agents

The platform is built to be operated by an agent: MCP tools, a strict --json contract, and a diagnose loop that names the fix.

Claude Code plugin

One install brings the MCP tools and a skill that teaches Claude the deploy workflow — the contract, build detection, and the diagnose-first loop for failures.

/plugin marketplace add neslyhq/claude-plugin
/plugin install nesly@nesly

MCP server

The CLI binary is also the MCP server — no second install. It uses the credentials the CLI is signed in with, or NESLY_TOKEN for headless use.

# any MCP client, e.g. Claude Code without the plugin
claude mcp add nesly -- nesly mcp

# headless (CI, a server): no browser session needed
nesly token create agent   # shown once
NESLY_TOKEN=nesly_pat_... nesly mcp

deploy_project	Pack a local directory, upload, build, wait, return the live URL.
diagnose_deployment	Why a deployment failed: evidence lines, missing env vars, a fix per finding. Call first after a failure.
get_logs / get_deployment	Raw logs and deployment detail when the diagnosis is not enough.
set_env / list_addons / add_addon	Environment and managed backing services (postgres and mssql; both inject DATABASE_URL, mssql also ConnectionStrings__Default).
rollback	Repoint traffic at a previous deployment, instantly.
add_domain / verify_domain	Custom domains: returns the DNS records to create, then verifies them.
connect_repository / redeploy	Push-to-deploy via the git integration, or rebuild without an upload.
get_usage	Requests, egress and build time over the last 30 days.

The --json contract

Every CLI command accepts --json and then prints exactly one JSON object on stdout; progress and logs go to stderr. Exit codes are stable: 0 ok, 1 error, 2 usage, 3 auth, 4 not found, 5 conflict. An agent that shells out instead of using MCP gets the same guarantees.

The diagnose loop

When a deploy fails, do not start by reading raw logs. nesly diagnose (or the diagnose_deployment tool) reads them for you and reports: the probable cause, the exact log lines as evidence, env vars the app reads but the project does not define, and the command that fixes each finding. Failure reasons across the platform are written to be actionable by the agent fixing the code — never "check your configuration".

$ nesly diagnose --project shop --json
{
  "status": "FAILED",
  "missing_env": ["STRIPE_KEY"],
  "findings": [{
    "cause": "the application reads the environment variable STRIPE_KEY, but the project does not define it",
    "evidence": ["TypeError: ... (process.env.STRIPE_KEY)"],
    "fix": "nesly env set STRIPE_KEY=<value> --project shop, then redeploy"
  }]
}

llms.txt

nesly.net/llms.txt is the one-page briefing: the deploy quickstart, the command list and the application contract (listen on $PORT, bind 0.0.0.0). AI assistants fetching the home page receive it directly.