Nine tools stand in for far more operations: each takes a schema selector and runs one named operation, and the read/write split is in the tool name itself, so a reader cannot deploy and an updater is never mistaken for a lookup. The cost is discoverability — what an updater can actually do is listed inside its description rather than in its name, which is how manage-env-vars and initialize-database end up behind generic-sounding tools. netlify-coding-rules is positioned as a required first call before writing functions or SDK code, so a coding session starts with a call that returns rules rather than data.
A server over the Netlify API grouped by service — user, team, project, deploy and extension — with a reader and, where writes exist, an updater, each dispatching to named operations.
- Deploys read and created: get-deploy and get-deploy-for-site on the reader, deploy-site on the updater
- Project administration in one place — create-new-project, update-project-name, manage-env-vars, update-visitor-access-controls, update-forms and manage-form-submissions
- Project and form reads through get-project, get-projects and get-forms-for-project
- Account context from get-user, get-teams and get-team
- Extensions listed and detailed, then acted on with change-extension-installation and initialize-database
- netlify-coding-rules, which the server asks to be called before any Netlify function or SDK code is written
A Netlify account, with the team and project you intend to act on already created in it.
One command — npx -y @netlify/mcp