Netlify MCP Server

Overview Schema Related Servers Score Discussions

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation3/5
The tools are grouped by resource type (deploy, extension, project, team, user), which provides some clarity, but the grouping approach creates ambiguity within each tool. For example, 'ntl-project-operations' bundles 9 different operations under one tool name, making it impossible for an agent to distinguish between them without reading the description. This forces the agent to parse the description to understand available actions, rather than having distinct tools for each operation.
Naming Consistency4/5
Most tools follow a consistent 'ntl-[resource]-operations' pattern (e.g., ntl-deploy-operations, ntl-project-operations), which is predictable. However, 'get-netlify-coding-context' deviates from this pattern, using a verb-noun format instead. This minor inconsistency reduces the overall naming coherence, but the majority of tools adhere to a clear convention.
Tool Count4/5
With 6 tools, the count is reasonable for a Netlify server, covering key areas like deployments, extensions, projects, teams, and users. It's slightly lean given the bundled operations, but each tool represents a logical domain, making the scope manageable. A few more tools could provide better granularity, but this is not a significant issue.
Completeness3/5
The server covers core Netlify domains (deployments, projects, teams, users, extensions) but has notable gaps. For example, there are no tools for creating or deleting deployments, managing site settings, or handling build operations. The bundled operations within tools suggest some coverage, but the surface is incomplete for full lifecycle management, which may cause agent failures in complex workflows.
Average 2.1/5 across 6 of 6 tools scored. Lowest: 1.5/5.
See the Tool Scores section below for per-tool breakdowns.
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. The description reveals nothing about whether operations are read-only or destructive, what permissions are required, rate limits, side effects, or response formats. For a tool with multiple mutation operations (update-visitor-access-controls, update-forms, etc.), this is critically inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is technically concise - a single sentence listing operations. However, this conciseness comes at the cost of being under-specified. While front-loaded with the operation list, it fails to provide necessary context that would help the agent understand and use the tool effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 9 distinct operations, multiple mutation capabilities, no annotations, no output schema, and 0% schema description coverage, this description is completely inadequate. It provides no context about what projects are, what Netlify operations entail, how results are returned, or any behavioral characteristics needed for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no parameters have descriptions in the schema. The description provides zero information about what parameters mean or how to use them. The agent must guess at parameter purposes from property names alone, which is insufficient for a tool with complex nested parameter structures across 9 different operations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description lists operation names but doesn't state what the tool actually does. It's essentially a tautology - restating that the tool runs operations without explaining what those operations accomplish. The agent must infer purpose from operation names alone, which is insufficient for clear understanding.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus the sibling tools (get-netlify-coding-context, ntl-deploy-operations, etc.). No context about prerequisites, appropriate scenarios, or distinctions between the listed operations. The agent receives zero usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but provides none. It doesn't indicate whether operations are read-only or destructive, what permissions are needed, what happens during execution, or what the expected outcomes are. The description fails to disclose any behavioral traits beyond the operation names.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is technically concise - a single sentence listing operation names. However, this conciseness comes at the cost of being severely under-specified. While it's front-loaded with the core instruction ('Run one of the following operations'), the lack of meaningful content makes this efficiency questionable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is completely inadequate for a tool with complex nested operations and no output schema. It doesn't explain what any operation does, what parameters they require, what results to expect, or how this tool relates to sibling tools. For a multi-operation tool with significant complexity, this description provides almost no useful context.
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?
The description provides no parameter information whatsoever. With 0% schema description coverage and 1 parameter (selectSchema) that contains complex nested structures for different operations, the description fails to compensate for the schema's lack of descriptions. It doesn't explain what selectSchema should contain or how to choose between the different operation schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description merely lists operation names without explaining what the tool actually does. It states 'Run one of the following operations' followed by operation names, which is a tautology that restates the tool's name ('operations') without providing specific verbs or resources. There's no indication of what these operations accomplish in the Netlify context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description doesn't explain what each operation does, so there's no basis for choosing between them or understanding when this tool should be used instead of sibling tools like ntl-deploy-operations or ntl-team-operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. However, it only lists an operation name without describing any traits—such as whether it's a read-only query, requires authentication, has rate limits, or what the output looks like. This leaves the agent with no insight into how the tool behaves beyond its name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence) and front-loaded, which is efficient, but it's under-specified rather than concise. It wastes space by being tautological ('Run one of the following operations get-user') without adding value, so while it's structured simply, it doesn't earn its place with useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (1 parameter with nested objects, 0% schema coverage, no annotations, no output schema), the description is completely inadequate. It doesn't explain the tool's purpose, usage, behavior, or parameters, leaving the agent unable to understand how to invoke it correctly. This fails to provide the minimal context needed for a tool with undocumented inputs and no structured metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter (a nested object with properties like 'operation' and 'params'), but schema description coverage is 0%, meaning parameters are undocumented. The description adds no meaning beyond the schema—it doesn't explain what 'aiAgentName', 'llmModelName', or 'params' are for, or how to use them. With low coverage and no compensation in the description, this fails to provide necessary parameter context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Run one of the following operations get-user' is tautological—it restates the tool name 'ntl-user-operations' and lists a single operation without explaining what 'get-user' actually does. It doesn't specify the verb (e.g., retrieve, fetch) or resource (e.g., user details, profile), nor does it differentiate from sibling tools like 'ntl-team-operations' or 'ntl-project-operations'.
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?
No guidance is provided on when to use this tool versus alternatives. It mentions 'get-user' but doesn't explain the context, prerequisites, or exclusions, such as when to use sibling tools like 'ntl-team-operations' for team-related user data. The description lacks any explicit when/when-not statements or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but fails completely. It doesn't indicate whether these operations are read-only or mutative (deploy-site clearly implies a write operation), what permissions are required, whether there are rate limits, or what happens during deployment. The description provides zero behavioral context beyond operation names.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence) but under-specified rather than efficiently informative. While it's front-loaded with the tool's scope, every word doesn't earn its place since it merely lists operation names without explaining them. The structure is simple but lacks substance.
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?
Given the complexity of a multi-operation tool with no annotations, no output schema, and rich input schema with three distinct operation patterns, the description is woefully incomplete. It doesn't explain what these operations do, their differences, expected outcomes, or error conditions. For a deployment-related tool that likely involves mutative operations, this is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and only 1 parameter (selectSchema), the description adds no parameter semantics beyond what's in the schema. However, since there's effectively 0 parameters from the agent's perspective (selectSchema is a wrapper for the actual operations), the baseline is 4. The description doesn't explain what selectSchema contains or how to choose between the three operation types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Run one of the following operations get-deploy, get-deploy-for-site, deploy-site' is a tautology that restates the tool name 'ntl-deploy-operations' in different words. It doesn't specify what these operations actually do (e.g., retrieve deployment information, deploy code to Netlify) or what resource they act upon. The description merely lists operation names without explaining their purpose.
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?
No guidance is provided on when to use this tool versus the sibling tools (get-netlify-coding-context, ntl-extension-operations, etc.). The description doesn't explain what scenarios call for get-deploy versus deploy-site, nor does it mention prerequisites or dependencies. Users must infer usage from operation names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states what operations can be run without mentioning whether these are read-only, require authentication, have rate limits, or what their outputs look like. For a tool with operations that likely fetch data, this leaves critical behavioral traits unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just one sentence listing the two operations. It's front-loaded with the core functionality, though it could benefit from more detail. There's no wasted verbiage, but it borders on under-specification.
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?
Given the tool's complexity (multiple operations with different parameter structures), lack of annotations, no output schema, and 0% schema description coverage, the description is incomplete. It doesn't explain what the operations return, how they differ, or provide any context about the Netlify system they operate on, leaving significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it provides no parameter information beyond naming the operations. The input schema shows a complex nested structure with 'selectSchema' containing operation-specific parameters, but the description doesn't explain what 'aiAgentName', 'llmModelName', or the operation-specific params mean. Baseline 3 is appropriate given the schema handles structure but lacks semantic explanation.
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 states the tool runs operations 'get-teams' or 'get-team', which provides a basic verb+action combination. However, it doesn't specify what resources these operations act upon (teams from what system?) or how they differ from each other. The purpose is vague but not tautological.
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?
No guidance is provided about when to use this tool versus its sibling tools (like ntl-user-operations or ntl-project-operations). The description merely lists the available operations without explaining their context, prerequisites, or appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the tool is a 'required step' but doesn't disclose behavioral traits like what it returns (e.g., configuration data, environment info), whether it's read-only, has side effects, or any constraints (e.g., rate limits, authentication needs). The description is insufficient for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the key usage instruction, and has no wasted words. It's appropriately sized for the tool's apparent complexity, though it could be more structured (e.g., separating purpose from guidelines).
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?
Given no annotations, no output schema, and low schema coverage, the description is incomplete. It covers usage context well but lacks details on what the tool does, its behavior, or return values. For a tool that seems to provide coding context, this leaves significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Parameter count is 1 with 0% schema description coverage, so the description must compensate. The description doesn't mention the 'creationType' parameter or its enum values, failing to add meaning beyond the schema. However, with only one parameter, the baseline is higher, but the lack of param info keeps it at a minimal viable score.
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 states the tool should be called when writing serverless or Netlify code, which gives a general purpose, but it's vague about what the tool actually does (e.g., fetch configuration, list resources, provide context). It distinguishes from siblings by focusing on coding context rather than operations, but lacks specific verb+resource clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: 'ALWAYS call when writing serverless or Netlify code' and 'required step before creating or editing any type of functions, Netlify sdk/library usage, etc.' This gives clear when-to-use guidance, though it doesn't explicitly mention when not to use or name alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![netlify-mcp MCP server](https://glama.ai/mcp/servers/tharunkalluru/netlify-mcp/badges/card.svg)](https://glama.ai/mcp/servers/tharunkalluru/netlify-mcp)

Score Badge

Copy to your README.md:

[![netlify-mcp MCP server](https://glama.ai/mcp/servers/tharunkalluru/netlify-mcp/badges/score.svg)](https://glama.ai/mcp/servers/tharunkalluru/netlify-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/tharunkalluru/netlify-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server