Netlify’s Get started with CLI guide reads like a developer onboarding page — npm install -g netlify-cli, netlify login, netlify init, netlify dev, netlify deploy --prod. Read it again and two of the commands on it are not aimed at a developer at all.
The first is netlify create "a landing page for a SaaS product with a waitlist signup". A prompt goes in, an AI Agent Runner generates the project, deploys it, and can wire up a GitHub repo with continuous deployment behind it. The second is netlify deploy --allow-anonymous — a deploy with no login, no token, no account, and a one-hour window in which a human can claim the site that just appeared. Netlify’s own docs describe that flag as being for AI agents and automated workflows.
That is a hosting platform shipping a credential-free write path on purpose, and documenting the blast radius as a countdown timer.
The CLI is the API wearing a coat
The guide is explicit that the CLI wraps the REST API, and it walks through the one identifier that ties the surfaces together: what the UI calls a Project ID is site_id in /api/v1/sites/{site_id}, and siteId / --site / NETLIFY_SITE_ID in the CLI and libraries. Same key, three doors.
So we went and re-profiled the provider to see how much of that door the catalog could actually describe. We were holding Netlify’s OpenAPI at version 2.33.1 — 133 operations. The live specification at open-api.netlify.com/swagger.json is 2.57.0, 180 operations. Forty-seven operations had shipped since anyone looked.
What the missing forty-seven turned out to be
They are not incidental. Split by resource, the new surface is almost entirely the agent-era platform:
| New API | What it does |
|---|---|
agentRunner |
create, list, update, archive an Agent Runner — plus agentRunnerPullRequest and agentRunnerCommitToBranch |
agentRunnerSession |
five operations managing a runner’s sessions |
agentRunnerHook |
event hooks on runner activity |
aiGateway |
provider list and scoped token issuance for AI calls |
database |
nineteen operations — branches, snapshots, migrations, compute settings |
edgeFunction |
deploy-time edge function upload |
netlify create is not a CLI convenience wrapped around a template gallery. There is a REST resource underneath it, and two of its operations open a pull request and commit to a branch. The prompt-to-production path is a first-class part of the platform’s contract.
apis.io/providers/netlify/ now carries 42 APIs split by resource, alongside one AsyncAPI describing the webhook and build-hook event surface, two Spectral rulesets, four pricing plans, and a rate-limit artifact. That rate-limit artifact is ours, generated by a sweep rather than harvested from Netlify, and it puts the Open API at 500 requests per minute per token and deploy creates at three per minute per site. Those are the API’s limits. netlify deploy spends them.
Discoverable from the domain root
The re-profile turned up something rarer than a stale spec. Netlify serves a genuine RFC 9727 API catalog at https://www.netlify.com/.well-known/api-catalog — application/linkset+json, anchoring two services: the REST API at api.netlify.com/api/v1, and the remote MCP server at netlify-mcp.netlify.app/mcp. That MCP host publishes RFC 8414 authorization-server metadata and RFC 9728 protected-resource metadata, and supports dynamic client registration. An anonymous tools/list returns 401 with a Bearer challenge, which is the correct answer.
Most providers make an agent read prose to find their MCP server. Netlify’s is reachable from the domain root by a machine that knows one well-known path.
Their agent skills are published the same way — fifteen SKILL.md files in netlify/context-and-tools, installed with npx skills add netlify/context-and-tools --skill '*' --yes, a line that appears in Netlify’s own llms.txt. Provider-authored agent skills are rare enough that across all of telecom they exist at three companies. Ours had never harvested them; they are in the catalog now.
What the agentic-access contract says about the risk
The catalog carries an x-agentic-access contract for Netlify covering 133 operations: 60 classified connected, 73 acting. Fifty-three of those are writes, and exactly one operation is flagged safety-critical with a human-in-the-loop requirement — disableSplitTest, the POST that unpublishes a traffic split. Short token TTL, proof-of-possession, purpose required, audit required.
That is a defensible read: most of Netlify is safe for a machine to drive, and the operation that silently changes what live traffic sees is not. Two honest caveats. The contract is derived — we wrote it from the OpenAPI, Netlify did not publish it — which is why it earns partial credit. And it was written against the 133-operation spec, so the Agent Runner and Database operations have no execution contract at all yet. The surface that most needs one is the newest.
Netlify’s current published score is 54.3, strong, with agent readiness at 26.0, agent-aware. Both were computed before this refresh landed; the catalog check for agent skills and the one for a well-known catalog will clear on the next scoring build, and we will report the number when we have seen it rather than predicting it.
The takeaway: when a platform’s CLI grows an anonymous deploy and a prompt-to-production command, the CLI has stopped being developer ergonomics and become an execution surface — and it inherits every limit, scope, and consequence the API underneath it defines. Netlify’s is worth reading operation by operation: apis.io/providers/netlify/.