multi-account-netlify-mcp

netlify-deploy-services-updater

Destructive

Deploy a project directory to Netlify for a single account, updating the target site while keeping changes scoped to that account.

Instructions

Select and run one of the following Netlify write operations deploy-site

Multi-account (the account argument): deploy-site: one account only, so a list or all is refused.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "selectSchema": "<selectSchema>"
    },
    "name": "netlify-deploy-services-updater"
  }
}

Input Schema

Name	Required	Description	Default
`account`	No	Netlify account to use: one name, several names separated by commas, or "all". Lists and all only work for operations that allow them; changes need one name. Leave out to use the default account. Accounts: none yet.
`selectSchema`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.3Oct 19, 2026

TDQS

C2.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description's contribution is the account-multiplexing constraint (lists/all refused for deploy-site), which is genuinely useful additional context, but it omits how the deploy is performed or what state it changes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The text is short but poorly structured: 'one of the following ... operations deploy-site' promises a list that never appears, and the account rule is repeated almost verbatim in the second sentence. The important scoping constraint is not front-loaded and the wording is confusing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, open-world write tool with a nested schema and no output schema, the description is far too thin. It gives no confirmation of what a successful deploy produces, no side-effect warnings beyond annotations, and no coverage of the two parameters that drive the operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 50%, so the description is expected to compensate. It restates the account restriction already present in the account parameter's schema text and says nothing about 'deployDirectory' or 'siteId', the parameters that actually matter for a correct deploy invocation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description identifies a scoped write operation ('Netlify write operations deploy-site') with a verb (run/select) and resource (deploy-site), and the sibling 'netlify-deploy-services-reader' makes the read/write split inferable. However, the phrasing 'one of the following ... operations deploy-site' is garbled and only lists a single operation, so an agent cannot cleanly tell what is being dispatched or how it differs from the other updaters.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The only guidance offered is that deploy-site takes a single account and refuses a list or 'all'. There is no statement of when to call this tool versus netlify-deploy-services-reader or the other updater siblings, and no prerequisites (e.g. linking a site) beyond what the schema notes.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server