Your agent needs to create sites, ship deploys, and manage projects on Netlify. Netlify ships an official MCP server and a full REST API, and both reach the same account. They are not the same object: different capability coverage, different auth entry points, and a different amount of operational surface you carry in production. This is the decision framework for picking one, written from the agent's side of the wire.
These are two different interfaces onto the same platform. One is a curated agent surface; the other is the complete programmatic API. Knowing exactly what each is keeps the later comparison honest.
Netlify launched its official Model Context Protocol (MCP) server in June 2025 during its Agent Week. It acts as a bridge that hands agents Netlify's API, CLI, and prompt context behind a single tool interface. Netlify recommends the remote server, reached at its hosted MCP endpoint with browser-based OAuth 2.1, and also ships a local server run with npx -y @netlify/mcp on Node.js 22 or higher. The local server can fall back to a NETLIFY_PERSONAL_ACCESS_TOKEN environment variable when interactive OAuth is not available. Setup details live in Netlify's MCP server documentation.
The Netlify REST API is the complete programmatic surface for the platform. Every request starts at https://api.netlify.com/api/v1/, is versioned in the path, and authenticates with an Authorization: Bearer token. It exposes sites, deploys, forms and submissions, environment variables, build hooks, DNS zones, functions metadata, and account and user records. The full reference is the Netlify REST API reference, and the auth setup is covered in Get started with the Netlify API.
Scalekit does not ship two Netlify connectors. It ships one, the Scalekit Netlify MCP connector, which wraps Netlify's official MCP server as a vendor MCP with per-user OAuth 2.1 and Dynamic Client Registration (DCR). It exposes 9 grouped tools spanning user, team, project, deploy, and extension services, plus a coding-context tool. Your agent calls those tools through Scalekit's execution layer; the Netlify token never touches your agent runtime.
Four dimensions decide this for an agent: what it can do, how it authenticates, what you operate in production, and which path fits the workload. The comparison below is Netlify-specific, not generic MCP advice.
The two surfaces agree on the build-and-ship loop and diverge at the edges. The table maps the actions that matter for agent use cases.
The MCP server is tuned for the code-to-production loop an interactive coding agent runs: scaffold a site, deploy it, wire env vars, toggle forms, and pull context on how to write Netlify functions correctly before generating code. Its coding-context tool is instructed to run before the agent writes any function code, which is a capability the raw API does not model. The REST API is the superset for everything else: DNS and domain management, build hooks, outgoing webhooks, and file-level deploy details. If your agent lives inside the deploy loop, the gap rarely bites. If it manages domains or wires webhooks, the API is the only path that reaches those.
Auth is where the two paths separate most sharply, and it is the part that decides whether an approach survives a second user. Both terminate at a user-scoped credential, but they get there differently.
The recommended Netlify MCP server uses browser-based OAuth 2.1 with DCR. That flow is designed for a human sitting in front of an editor: the agent opens a consent screen, the user approves, and the client holds the resulting token. The local server can instead read a single NETLIFY_PERSONAL_ACCESS_TOKEN from its environment, which is fine for one developer's machine and does not model more than one identity.
The REST API accepts a Personal Access Token as a bearer credential, or an OAuth2 app that runs the Authorization Code flow to act on behalf of a user. PATs support configurable expiration and an explicit opt-in for SAML-based teams. OAuth2 apps are the correct choice for a public integration acting for many users. Both resolve to a single Netlify user's permissions.
Netlify has no team-scoped, non-interactive installation credential analogous to a GitHub App installation token. Every path represents one Netlify user. In a multi-tenant B2B agent, that means one connected account per user: a token per customer to store, refresh, and revoke. The path you choose changes the token type; it does not change the requirement. This is where per-user connected accounts and multi-tenant access control become the load-bearing part of the design.
The operational question is simple: when something breaks, who fixes it, and what did that path make your responsibility. The two answers are different in scope.
With the remote MCP server, Netlify owns hosting, tool schemas, and updates. You do not patch a server or track endpoint changes tool by tool. What you still own is the credential lifecycle: the OAuth token per user, its storage outside the agent runtime, its refresh, and its revocation. You also inherit schema drift risk; when Netlify updates the server, tool signatures can move without a versioning contract, so an agent bound to a specific tool shape may need attention after upstream changes.
With the REST API you own endpoint selection, request construction, pagination, retries, error handling, and the full token lifecycle. The maintenance surface is larger. The tradeoff is stability: the API is versioned in the path, and backward-incompatible changes bump the version marker. For a nightly, deterministic pipeline calling the same handful of endpoints, that predictability is worth the extra code.
Use Netlify MCP when:
Use the Netlify REST API directly when:
The auth divergence between the two paths, OAuth for MCP versus PAT or OAuth2 for the API, hides the problem that sits under both choices. It is the same problem, and it is the reason this decision matters less than it looks.
Both paths hand you a token per user. Neither hands you a vault, a rotation loop, or a revocation flow. In a multi-tenant B2B agent, that is N credentials, one per user, each with its own expiry and its own lifecycle. Tokens have to live outside the agent runtime, encrypted at rest and isolated per tenant. Refresh has to be proactive; waiting for a 401 creates race conditions when multiple agent threads try to refresh the same token at once. Revocation has to surface and invalidate every credential tied to an identity when a customer churns or an employee leaves. The MCP server and the REST API each stop at issuing the token; the lifecycle after that is yours. For a deeper look at these challenges, see how to handle token refresh for AI agents.
The Scalekit Netlify connector handles the OAuth flow, token storage, and rotation for Netlify, so the MCP versus API decision does not change your auth infrastructure. Connected accounts and connections abstract token storage, refresh orchestration, and tenant isolation; your agent executes against a scoped identifier, not a raw token. That is the whole point: pick the interface on capability grounds, not because one of them is easier to authenticate.
Here is a complete, per-user Netlify agent in Python using the Anthropic Claude SDK. Scalekit holds the token; your code resolves an identifier and calls scoped tools. The sequence is discovery, then scope, then execution.
Install pip install anthropic scalekit-sdk-python protobuf. In the Scalekit dashboard, under AgentKit and then Connections, create a Netlify MCP connection and give it a name. The connection_name in your code must match that dashboard name character for character; it is case-sensitive, and a mismatch returns an empty tool list with no error. Full setup is in the AgentKit Python SDK reference.
The agent can only act as a user who has connected their Netlify account. get_or_create_connected_account checks status; if it is not ACTIVE, get_authorization_link returns the URL that runs Netlify's OAuth flow. The identifier comes from your own authenticated session, never from the client.
list_scoped_tools returns the tools this identifier's connected account is authorized to call, in Anthropic's native format. This is not a flat connector catalog; it is the surface that one user's grant permits. The Scalekit SDK returns protobuf objects, so MessageToDict converts each tool definition into a plain dict the Anthropic SDK accepts.
This is the standard Anthropic tool-use loop. Claude decides what to call; your code runs execute_tool with the same identifier, and Scalekit calls Netlify with that user's stored token. The try and except feeds tool errors back to Claude instead of crashing the loop. The full loop is shown, nothing truncated.
The same pattern works across frameworks; the Anthropic example and the wider Scalekit connector catalog show the identical connected-account flow for LangChain, Google ADK, CrewAI, and Mastra.
Wrapping Netlify through Scalekit changes three things that matter once the agent is real: scope, multi-tenant deployment shape, and observability. Each maps to a failure the naive path hits at scale.
A shared PAT in an environment variable gives every user of the agent the same access, the same team, and the same permissions. That works in a demo and breaks on the second user. Connected accounts invert it: scope is a function of identity, derived from what each user individually authorized. What the user cannot do, the agent cannot do. For a deploy agent, that means it acts inside each customer's own Netlify account, not a shared one, and cross-tenant reach is closed at the token level rather than by convention. This is one of the key auth differences when moving from single-tenant to multi-tenant tool calling.
Netlify's MCP surface is modest, but real agents rarely stop at one tool. A deploy agent that also touches GitHub and Slack quickly accumulates a large tool surface, and a full catalog degrades tool selection and burns tokens before the agent does any work. Scalekit Virtual MCP servers fix this at the tool level: one server definition, per-user credential isolation, and least-privilege tool access. The agent sees only the tools you explicitly allow, not everything each connector exposes. One definition serves every user; before each run, a short-lived session token is minted scoped to that user's connected accounts. There is no MCP server for you to deploy, host, or maintain. This is the model behind multi-tool builds like the DevOps assistant agent and the incident response agent.
When an agent deploys to production on a user's behalf, you need to answer who called what, as whom, and when. Audit trails for agent auth record every authorization and tool-calling event tied to the connected account, which gives downstream tool-calling agents a queryable audit trail without you instrumenting each call. That is the record a security review asks for the moment your agent starts shipping deploys across customer accounts.
If your agent is an interactive coding assistant that scaffolds and ships inside an editor, Netlify MCP is the right path: Netlify runs the server, OAuth handles consent, and the coding-context tool sharpens generated code. If your agent is headless, scheduled, or needs DNS, domains, or webhooks, the REST API is the only surface that reaches them. Either way, the credential problem is identical: one user-scoped token per customer, stored, refreshed, and revoked outside the agent. That is the part that needs production-grade infrastructure, and it is the part the interface choice does not solve. Understanding who holds the token across agent tool-calling patterns is essential before committing to either path. Compare plans on the Scalekit pricing page and the AgentKit and Agent Gateway pricing.
Read the Scalekit Netlify connector docs and browse the Netlify connector page to wire up per-user Netlify access. For help while you build, join the Scalekit community on Slack or talk to the Scalekit team for immediate answers.
