This server allows you to manage DigitalOcean cloud infrastructure through an AI assistant, covering the following capabilities:
Droplets: List, get details, create (specifying name, region, size, image, SSH keys, and tags), and delete virtual servers.
Databases: List and get details about managed database clusters.
Domains: List, create (with an associated IP/A record), and delete domains.
Infrastructure: Browse available datacenter regions and Droplet sizes with pricing and capability details.
Account: View your DigitalOcean account information, email, UUID, and usage limits.
Manages DigitalOcean cloud resources, including account info, Droplets (list, get, create, delete), managed databases, domains, regions, and sizes.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-server-digitalocean List all my Droplets"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol server for DigitalOcean cloud infrastructure. Manage Droplets, databases, domains, and more — all through your AI assistant.
Manage Droplets — list, create, get details, and delete Droplets
Query Databases — list and inspect managed database clusters
Handle Domains — list, create, and delete domain records
Explore Infrastructure — browse available regions and Droplet sizes with pricing
Check Account — view account info and usage limits
Related MCP server: PlugLayer MCP Server
Python >= 3.10
A supported MCP client:
uv tool install mcp-server-digitaloceanpip install mcp-server-digitaloceanGo to DigitalOcean API Tokens and create a new Personal Access Token.
Add this JSON snippet to your client's MCP config file:
{
"mcpServers": {
"digitalocean": {
"command": "uvx",
"args": ["mcp-server-digitalocean"],
"env": {
"DIGITALOCEAN_TOKEN": "YOUR_DO_TOKEN"
}
}
}
}Then follow the instructions for your specific client:
Go to Settings > Developer > Edit Config
Add the snippet above to claude_desktop_config.json
Replace YOUR_DO_TOKEN with your token
Save and restart Claude Desktop
You'll see "digitalocean" listed as an available server
Go to Settings > Cursor Settings > MCP > Add a new global MCP server
Cursor will open ~/.cursor/mcp.json
Add the snippet above to this JSON file
Replace YOUR_DO_TOKEN with your token
Save and return to MCP Settings
Go to Settings > Windsurf Settings > Cascade > MCP > Add Server > Add custom server
Windsurf will open ~/.codeium/windsurf/mcp_config.json
Add the snippet above to this JSON file
Replace YOUR_DO_TOKEN with your token
Save and return to MCP Settings
Run in your terminal:
claude mcp add digitalocean -- uvx mcp-server-digitaloceanSet the environment variable:
export DIGITALOCEAN_TOKEN="your-token-here"Category | Tools |
Account |
|
Droplets |
|
Databases |
|
Domains |
|
Infrastructure |
|
Once configured, try asking your assistant:
"List all my Droplets"
"Create a new 1GB Droplet in NYC1 running Ubuntu 24.04"
"Show me all available regions"
"List my database clusters"
"Delete droplet 42"
"What Droplet sizes are available and how much do they cost?"# Clone the repo
git clone https://github.com/truecallerabreham/mcp-server-digitalocean.git
cd mcp-server-digitalocean
# Install dependencies
uv sync
# Run tests
uv run pytest
# Run linter
uv run ruff check src/ tests/
# Type check
uv run pyrightMake sure your JSON config is saved and valid (no trailing commas)
Restart your MCP client (Claude, Cursor, Windsurf)
Check that uvx is in your PATH
Verify the token has the correct scopes
Try generating a fresh one at DigitalOcean API Tokens
Test the server directly:
DIGITALOCEAN_TOKEN="your-token" uvx mcp-server-digitaloceanContributions are welcome! Bug reports, new features, and docs improvements are all appreciated.
Fork this repo
Create a branch (git checkout -b feature/my-feature)
Make your changes
Run tests (uv run pytest)
Open a PR
This project is licensed under the MIT License.
Create a new domain in your account.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The domain name (e.g., 'example.com') | |
| ip_address | Yes | The IP address for the domain's A record |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate write (readOnlyHint=false) and idempotent (idempotentHint=true) behavior. Description adds alignment but no further behavioral details such as error states or propagation time. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with 8 words, efficient and front-loaded. However, it could include more useful details without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 2 parameters and no output schema, the description is minimal but adequate for a simple creation tool. Missing information about success response or validation rules.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds no extra meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'create' and the resource 'domain', with scope 'in your account'. It distinguishes from sibling tools like delete_domain and create_droplet.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 alternatives, no prerequisites or context provided. For example, it doesn't mention that the domain must be unique or that DNS records may need configuration.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new Droplet. Specify name, region, size, and image.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Human-readable name for the Droplet | |
| size | Yes | Size slug (e.g., 's-1vcpu-1gb', 's-2vcpu-4gb') | |
| tags | No | Optional array of tag names | |
| image | Yes | Image slug or ID (e.g., 'ubuntu-24-04-x64') | |
| region | Yes | Region slug (e.g., 'nyc1', 'sfo3', 'lon1') | |
| ssh_keys | No | Optional array of SSH key IDs to add |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a mutating operation (readOnlyHint=false), but description adds no behavioral details such as side effects, billing implications, or return value. Without an output schema, more transparency is warranted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no filler, front-loaded with the action 'Create'. Could be more structured but remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters and no output schema, the description is too sparse. Does not mention optional parameters (tags, ssh_keys) or any return behavior, leaving gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters are already documented. The description merely lists the required parameters, adding no extra meaning. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a new Droplet and lists the key required parameters (name, region, size, image). This distinguishes it from sibling tools like delete_droplet or list_droplets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 alternatives like create_domain. Lacks context about prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a domain from your account.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The domain name to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds no behavioral traits beyond the obvious deletion action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is concise and not verbose, but lacks structure or additional context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one simple parameter and no output schema, the description is minimally adequate but does not discuss consequences (e.g., irreversibility) or error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%; the description does not add meaning beyond the schema's description of the 'name' parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Delete') and resource ('domain'), and clearly distinguishes from sibling tools like create_domain and delete_droplet.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives, nor any prerequisites (e.g., domain must exist). The description is purely declarative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Permanently delete a Droplet. This action is irreversible.
| Name | Required | Description | Default |
|---|---|---|---|
| droplet_id | Yes | The Droplet ID to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds 'irreversible' beyond annotations (destructiveHint, idempotentHint). Consistent with annotations; no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with action and consequence. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-param destructive tool with annotations, description is sufficient. No output schema needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 100%; description adds no extra meaning beyond the schema's parameter description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb and resource: 'delete a Droplet' with emphasis on permanence. Distinguishes from siblings like create_droplet, list_droplets, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use or not use. Does not mention alternatives or prerequisites, leaving agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get your DigitalOcean account information including email, UUID, and account limits.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds value by specifying the returned data (email, UUID, account limits), which is consistent and enhances transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, directly stating the action and key outputs. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description mentions key return fields. Could specify structure of account limits or error conditions, but sufficient for a simple getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. Baseline is 4, and the description does not need to add parameter info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves DigitalOcean account information, listing specific data (email, UUID, account limits). It distinguishes itself from siblings, which focus on domains, droplets, databases, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool vs alternatives, but given that no sibling tool provides account info, the context is clear. It implicitly indicates it's the only option for account details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific database cluster.
| Name | Required | Description | Default |
|---|---|---|---|
| database_id | Yes | The database cluster UUID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description does not add behavioral context beyond what annotations provide, but does not contradict them either.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with key action and resource, no extraneous words. Highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one required parameter and no output schema, the description is mostly adequate. However, it could mention the type of information returned (e.g., region, version) to set expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters. The single parameter database_id has a schema description 'The database cluster UUID'. Description adds no extra meaning; baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get detailed information about a specific database cluster', specifying the verb (get), resource (database cluster), and scope (specific). This distinguishes it from siblings like list_databases which would list all clusters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 alternatives such as list_databases for listing or get_droplet for droplets. The description provides no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific Droplet by its ID.
| Name | Required | Description | Default |
|---|---|---|---|
| droplet_id | Yes | The Droplet ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds 'detailed information' but no extra behavioral context (e.g., response size, pagination, authentication). With annotations covering safety, a 3 is appropriate – adequate but not enriching.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no unnecessary words. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 param, read-only, no output schema), the description is mostly complete. It explains what the tool does and how to use it. However, it does not mention what the 'detailed information' includes or any prerequisites (e.g., authentication). Still, it is adequate for a safe, simple retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description does not add any extra meaning beyond the schema's 'The Droplet ID'. The schema already fully describes the parameter, so baseline 3 is correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Get' and the resource 'detailed information about a specific Droplet by its ID'. It distinguishes well from siblings like list_droplets (list all), create_droplet, and delete_droplet.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a specific Droplet ID, but does not explicitly state when to use this tool versus alternatives like list_droplets. No when-not or alternative mentions, leaving it to the agent to infer from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all database clusters in your account.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds no further behavioral context. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words, front-loaded with verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters and clear annotations, the description is sufficiently complete. No output schema needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters; schema coverage is 100%. Description does not need to add parameter info. Baseline 4 for 0-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'list' and resource 'database clusters' with scope 'in your account'. It distinguishes from sibling tools like create_database or delete_database.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 alternatives, such as get_database for a specific cluster. No mention of prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all domains in your account.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds no extra behavioral context beyond stating it lists domains, so it does not exceed the baseline. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no waste, front-loaded with the core purpose. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no params, clear annotations, no output schema), the description is nearly complete. However, it does not hint at the return format or data structure, which could be useful for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in the input schema, so schema description coverage is 100%. Baseline for zero parameters is 4. Description adds no parameter information as none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'list' and resource 'domains', clearly stating the tool lists all domains in the account. It distinguishes from sibling tools like create_domain and delete_domain by its listing nature, and from other list tools by specifying 'domains'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. No mention of when not to use or comparison with sibling list tools like list_databases. The description only states what it does without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Droplets in your account. Returns droplet IDs, names, statuses, IPs, regions, and sizes.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number for pagination (default: 1) | |
| per_page | No | Items per page, max 200 (default: 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true, so description adds value by specifying returned fields. Consistent and enough behavioral context for a read-only list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence concisely states purpose and output, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main purpose and output fields, but lacks mention of default pagination behavior or total count; still adequate for a straightforward list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for page and per_page. Description does not add extra meaning beyond the schema, meeting baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'List all Droplets in your account' with specific verb and resource, and enumerates returned fields (IDs, names, statuses, etc.), distinguishing it from sibling tools like list_databases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for listing droplets but does not explicitly state when to use this tool vs. alternatives like get_droplet or other list tools. No exclusions or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available DigitalOcean datacenter regions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description adds 'all available' context but no additional behavioral traits. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence with no waste. Perfectly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless list tool with no output schema, the description is complete enough. It fully explains the tool's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters; schema coverage is 100%. Description doesn't need to add parameter info. Baseline 4 for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and resource 'regions', and it distinguishes from sibling tools like list_droplets or list_sizes by being specific to datacenter regions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives, but given it has no parameters and is a simple list, it's self-evident. Slight improvement could mention use case for getting region IDs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available Droplet sizes with pricing and capability info.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false; description adds specific context about output (pricing and capability info), which is consistent and sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with core action, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description is mostly complete but could elaborate on specific fields in the output for better context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and 100% schema coverage, so the description's lack of parameter details is acceptable; baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the verb 'List' and the resource 'available Droplet sizes with pricing and capability info', clearly distinguishing from sibling tools like list_regions or list_domains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving Droplet size information but provides no explicit guidance on when to use it vs alternatives or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0create_domaincreate_dropletdelete_domaindelete_dropletget_accountget_databaseget_dropletlist_databaseslist_domainslist_dropletslist_regionslist_sizesEach tool targets a distinct resource and action: create, delete, get, list for droplets and domains; get/list for databases; list for regions and sizes; and get_account for account info. No overlap.
All tools follow a consistent verb_noun pattern in snake_case (e.g., create_droplet, list_domains). No mixing of conventions.
12 tools is well-scoped for a DigitalOcean API server, covering key resources without being excessive or too few.
Basic CRUD for droplets and domains is covered, but missing update operations, database creation/deletion, and droplet actions (e.g., power on/off). Notable gaps exist.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Interact with the Stitch API using natural language commands.
Deploy, monitor, and manage your OpenClaw AI assistants via natural language.
Interact with your Google Cloud Firestore resources using natural language commands.
Deploy and manage applications, databases, domains, and git repos
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/truecallerabreham/mcp-server-digitalocean'
If you have feedback or need assistance with the MCP directory API, please join our Discord server