Offers zone management, advanced DNS operations with proxy settings, cache control (purge by URL, tags, or all), traffic and performance analytics, and security settings like SSL and firewall rules.
Enables complete droplet lifecycle management, DNS record CRUD operations, account information retrieval, and image management including distributions and snapshots.
Provides full lifecycle management for containers (create, start, stop, remove, logs), image operations (list, pull), system information (stats, health), and resource monitoring.
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., "@cargoshipper-mcp list my Docker containers"
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 comprehensive MCP (Model Context Protocol) server that provides Claude with direct access to Docker, DigitalOcean, and CloudFlare APIs for infrastructure management and automation.
USE AT YOUR OWN RISK: This tool gives AI models direct access to infrastructure management APIs that can:
Create, modify, or delete cloud resources (potentially incurring costs)
Modify DNS settings (potentially breaking domains)
Manage Docker containers and images (potentially affecting running services)
Execute destructive operations on your infrastructure
Before using:
Ensure you understand the capabilities and risks of each API
Start with non-production environments only
Review all operations before execution in production
Monitor costs and resource usage carefully
Have backup and recovery procedures in place
AI models may:
Misinterpret instructions and perform unintended operations
Make mistakes in resource configuration or deletion
Execute multiple operations when only one was intended
Struggle with complex multi-step procedures requiring human judgment
Recommended safety measures:
Use dedicated development/testing accounts with spending limits
Implement least-privilege API tokens with restricted permissions
Monitor all operations through cloud provider dashboards
Test operations in isolated environments first
Keep backups of critical configurations and data
Related MCP server: easypanel-mcp-server
This project welcomes contributions from AI/LLM agents! Pull requests from Claude, GPT, and other AI models are actively encouraged.
Guidelines for AI contributors:
Follow existing code patterns and documentation standards
Include comprehensive commit messages explaining changes
Test changes thoroughly before submitting PRs
Update documentation when adding new features
CargoShipper is available on PyPI and works seamlessly with uvx for easy installation and management, just like mcp-server-git.
# Run directly (recommended)
uvx cargoshipper-mcp
# Configure in your .mcp.json
{
"mcpServers": {
"cargoshipper": {
"command": "uvx",
"args": ["cargoshipper-mcp"]
}
}
}For local development and testing:
Clone the repository:
cd cargoshipper-mcpInstall dependencies:
pip install -r requirements.txt
# or create a virtual environment first
python3 -m venv .venv
source .venv/bin/activate # Linux/Mac
pip install -r requirements.txtConfigure your APIs:
cp .env.example .env
# Edit .env with your API tokens:
# DIGITALOCEAN_TOKEN=your_token_here
# CLOUDFLARE_API_TOKEN=your_token_hereUse the development MCP configuration:
# Use .mcp.dev.json for local development
cp .mcp.dev.json .mcp.jsonContainer Management: Full lifecycle (create, start, stop, remove, logs)
Image Operations: List, pull, and manage Docker images
System Information: Docker system stats and health
Resource Monitoring: Container resource usage and status
Droplet Management: Complete droplet lifecycle management
DNS Management: Full DNS record CRUD operations
Account Information: Access account details and billing
Image Management: Work with distributions and custom snapshots
Zone Management: Create and configure CloudFlare zones
DNS Operations: Advanced DNS with proxy settings
Cache Control: Purge cache by URL, tags, or everything
Analytics: Traffic and performance analytics
Security Settings: SSL, security levels, firewall rules
30 Tools Total:
Docker (9 tools): docker_run_container, docker_list_containers, etc.
DigitalOcean (10 tools): do_create_droplet, do_list_dns_records, etc.
CloudFlare (11 tools): cf_create_zone, cf_purge_cache, etc.
17 Resources Total:
docker://containers - All containers with status
digitalocean://droplets - All droplets with costs
cloudflare://zones - All zones with analytics
And many more...
{
"mcpServers": {
"cargoshipper": {
"command": "uvx",
"args": ["cargoshipper-mcp"]
}
}
}{
"mcpServers": {
"cargoshipper": {
"command": "python",
"args": ["-m", "cargoshipper_mcp.server"],
"cwd": ".",
"env": {
"PYTHONPATH": "."
}
}
}
}Create .env file or ~/.config/cargoshipper-mcp/.env:
# DigitalOcean API Token
DIGITALOCEAN_TOKEN=your_digitalocean_token_here
# CloudFlare API Token (recommended)
CLOUDFLARE_API_TOKEN=your_cloudflare_token_here
# Alternative: CloudFlare Email + Global API Key
# CLOUDFLARE_EMAIL=your@email.com
# CLOUDFLARE_API_KEY=your_global_api_keyGetting API Tokens:
DigitalOcean: API Tokens Page
CloudFlare: API Tokens Page
Once configured, Claude will have access to infrastructure operations:
# Docker examples
"Run an nginx container on port 8080"
"List all running containers"
"Get logs from container abc123"
# DigitalOcean examples
"Create a small droplet in NYC3"
"List all my droplets and their costs"
"Add an A record for api.example.com"
# CloudFlare examples
"Create a new zone for mysite.com"
"Purge all cache for example.com"
"Show me analytics for the last 24 hours"cargoshipper-mcp/
āāā cargoshipper_mcp/ # Main package (renamed from src/)
ā āāā server.py # MCP server entry point
ā āāā config/ # Configuration with multi-path .env loading
ā āāā tools/ # API operation tools
ā ā āāā docker.py # Docker operations
ā ā āāā digitalocean.py # DigitalOcean operations
ā ā āāā cloudflare.py # CloudFlare operations
ā āāā resources/ # Read-only data access
ā āāā utils/ # Shared utilities
āāā .mcp.json # Production MCP config (uvx)
āāā .mcp.dev.json # Development MCP config (local python)
āāā pyproject.toml # Python packaging (uvx compatible)
āāā requirements.txt # Dependencies
āāā install.sh # uvx installation scriptCargoShipper MCP is now available on PyPI! Access it at: https://pypi.org/project/cargoshipper-mcp/
Setup is as simple as:
# Run directly (most common)
uvx cargoshipper-mcp
# Configure in .mcp.json
{
"mcpServers": {
"cargoshipper": {
"command": "uvx",
"args": ["cargoshipper-mcp"]
}
}
}Uses proper Python packaging with pyproject.toml
Console entry point: cargoshipper-mcp = "cargoshipper_mcp.server:main"
Multi-path environment loading for uvx compatibility
Type hints and comprehensive error handling throughout
python test_server.py # Validates imports and configurationThis approach follows the same pattern as mcp-server-git and other uvx-compatible MCP servers, making it extremely easy to install and use once published!
Create a DNS record
Args: zone_id: CloudFlare zone ID record_type: DNS record type (A, AAAA, CNAME, MX, TXT, etc.) name: Record name (subdomain or @ for root) content: Record content (IP address, domain name, etc.) ttl: Time to live (1 = Auto, 120-7200 seconds) proxied: Whether to proxy through CloudFlare (orange cloud) priority: Priority for MX records
| Name | Required | Description | Default |
|---|---|---|---|
| zone_id | Yes | ||
| record_type | Yes | ||
| name | Yes | ||
| content | Yes | ||
| ttl | No | ||
| proxied | No | ||
| priority | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that the tool creates a record and explains parameters like proxied and ttl, which imply behavior. However, it does not mention error handling, idempotency, or what happens if the record already exists, leaving gaps for an agent.
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?
The description is structured as a clear list with an opening statement, front-loading the purpose. It is concise enough, though the parameter list could be slightly more terse. No redundant sentences.
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 existence of an output schema, the description does not need to cover return values. It thoroughly explains all 7 parameters. However, it lacks context on failure modes, duplicate handling, and dependencies (e.g., zone existence), which are relevant for a creation 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?
The input schema has no descriptions (0% coverage), so the description is the sole source. It explains each parameter with meaningful details (e.g., 'TTL: Time to live (1 = Auto, 120-7200 seconds)', 'priority: Priority for MX records'), adding significant value beyond the schema's type and title.
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 'Create a DNS record', matching the tool name and clearly indicating a creation action. It is distinct from sibling tools like cf_update_dns_record and cf_delete_dns_record, making the tool's purpose unambiguous.
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 is provided on when to use this tool versus alternatives. While its purpose is clear, there is no mention of prerequisites (e.g., zone must exist) or situations where updating or deleting is more appropriate, leaving the agent without decision context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new CloudFlare zone
Args: name: Domain name for the zone account_id: CloudFlare account ID jump_start: Import existing DNS records automatically zone_type: Zone type ('full' or 'partial')
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| account_id | Yes | ||
| jump_start | No | ||
| zone_type | No | full |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description omits behavioral traits such as permission requirements, zone initialization states, or rate limits. The mutation intent is clear but insufficient disclosure.
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?
Description is brief (6 lines) and uses a clear 'Args:' structure. No wasted words, though could be slightly more organized.
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 basic creation purpose and parameters, but lacks usage context and behavioral details. Output schema exists (not shown), so return value explanation is forgivable. Incomplete for a 4-param creation 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 has 0% description coverage, but the description compensates by explaining each parameter: 'name' as domain name, 'account_id' as account ID, 'jump_start' for auto-import, and 'zone_type' with allowed values ('full' or 'partial'). Adds meaning beyond schema titles.
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 'Create a new CloudFlare zone', specifying the verb and resource. It distinguishes from siblings like cf_delete_zone and cf_get_zone. However, it could elaborate on what a zone represents (e.g., domain).
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, or any prerequisites (e.g., domain verification). Lacks explicit context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a DNS record
Args: zone_id: CloudFlare zone ID record_id: DNS record ID
| Name | Required | Description | Default |
|---|---|---|---|
| zone_id | Yes | ||
| record_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It indicates deletion is destructive but does not disclose side effects, permissions, or reversibility. There is no mention of error conditions or idempotency.
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?
The description is concise with one sentence for purpose and clear parameter mapping under 'Args:'. No wasted words, though it could be more front-loaded by putting the purpose first.
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 delete operation, the description provides minimal context. It does not explain the output schema or error conditions. While the tool is straightforward, there is room for improvement in providing complete guidance.
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 description coverage is 0%, but the description adds meaning by defining 'zone_id' as 'CloudFlare zone ID' and 'record_id' as 'DNS record ID', which the schema's titles lack. This compensates for the low coverage.
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 'Delete a DNS record', which is a specific verb and resource. It distinguishes from sibling tools like cf_create_dns_record and cf_update_dns_record.
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 cf_update_dns_record or cf_list_dns_records. No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a CloudFlare zone
Args: zone_id: CloudFlare zone ID
| Name | Required | Description | Default |
|---|---|---|---|
| zone_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only states 'Delete' without disclosing side effects, irreversibility, permissions, or other behavioral traits.
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?
The description is very short and front-loaded. While concise, it could be considered under-specified for a destructive action, but it effectively communicates the core purpose.
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 destructive tool with no annotations and an output schema, the description should explain return values, error handling, and safety considerations. It omits these, making it incomplete.
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 description coverage is 0%, and the description adds 'CloudFlare zone ID' for the parameter, giving context beyond the schema's title. However, it lacks details on format or how to obtain the ID.
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 'Delete a CloudFlare zone' with a specific verb and resource. It distinguishes from sibling tools like cf_create_zone and cf_list_zones.
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 cf_delete_dns_record. The description does not mention prerequisites or context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get zone analytics
Args: zone_id: CloudFlare zone ID since: Start time (ISO 8601 format) until: End time (ISO 8601 format) continuous: Return continuous data (True) or time series (False)
| Name | Required | Description | Default |
|---|---|---|---|
| zone_id | Yes | ||
| since | Yes | ||
| until | Yes | ||
| continuous | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavioral traits, but it only lists parameters. It does not mention read-only nature, authentication needs, rate limits, or error handling. The word 'get' implies a read operation, but no explicit safety guarantees are given.
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?
The description is extremely concise: one line for purpose followed by a bullet list of parameters. Every word earns its place, and the structure is clear 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?
The description is sufficient to understand that this tool retrieves analytics for a CloudFlare zone with time filtering. An output schema exists, so return values are covered. However, it lacks operational context like available metrics or pagination, but given the simplicity, it is mostly complete.
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?
With 0% schema coverage, the description fully explains each parameter: zone_id, since/until formats (ISO 8601), and continuous flag. This adds significant meaning beyond the schema's type and title alone.
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 'Get zone analytics' clearly states the verb and resource, distinguishing it from siblings like cf_get_zone and cf_get_zone_settings which serve different purposes.
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 is provided on when to use this tool versus alternatives. The description only states the basic function, without any when-not-to-use context or pointers to sibling tools.
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 zone
Args: zone_id: CloudFlare zone ID
| Name | Required | Description | Default |
|---|---|---|---|
| zone_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It states it is a get operation but does not explicitly confirm it is read-only or disclose any side effects. More transparency is needed.
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?
The description is short, with no wasted words. The Args section is slightly redundant but acceptable. Could be more structured.
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 get operation with an output schema, the description is adequate but could mention what 'detailed information' includes to be fully complete.
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?
Only one parameter, zone_id, and the description adds 'CloudFlare zone ID' which provides context beyond the schema. However, with 0% schema coverage, a more thorough description would be beneficial.
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 gets detailed information about a specific zone. However, it does not explicitly distinguish from sibling tools like cf_get_zone_settings, leaving differentiation implied.
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. The description only states what it does, not when 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.
Get CloudFlare zone settings
Args: zone_id: CloudFlare zone ID
| Name | Required | Description | Default |
|---|---|---|---|
| zone_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only states the action and parameter, no disclosure of side effects, rate limits, authentication needs, or error behavior. Minimal behavioral insight.
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?
Extremely concise: two lines. No unnecessary information. Front-loaded with tool purpose.
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?
Despite having an output schema, the description lacks context about what zone settings are, output structure, or prerequisites. Incomplete for a tool that returns settings data.
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 0%; description repeats 'zone_id: CloudFlare zone ID'. Adds no extra meaning beyond the parameter name. Does not clarify format, constraints, or examples for the single 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 clearly states 'Get CloudFlare zone settings', specifying the verb (get) and resource (zone settings). It distinguishes from siblings like cf_get_zone (which gets the zone itself) and cf_update_zone_setting (update).
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. The description does not mention prerequisites, when not to use, or any context for selection among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List DNS records for a zone
Args: zone_id: CloudFlare zone ID record_type: Filter by record type (A, AAAA, CNAME, etc.) name: Filter by record name content: Filter by record content
| Name | Required | Description | Default |
|---|---|---|---|
| zone_id | Yes | ||
| record_type | No | ||
| name | No | ||
| content | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as pagination, rate limits, or authentication requirements, leaving the agent without important context beyond the basic 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?
The description is concise, front-loaded with the purpose, and follows a clear docstring format listing arguments, with no extraneous information.
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?
The description covers the basic parameters and purpose, but lacks mention of output format, pagination, or limits. However, the presence of an output schema partially mitigates the need for return value explanation.
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?
With 0% schema description coverage, the description compensates by explaining each parameter's purpose (e.g., 'Filter by record type'), adding meaning beyond the schema's titles.
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 'List DNS records for a zone' which is a specific verb+resource combination, differentiating it from sibling tools like cf_create_dns_record or cf_delete_dns_record.
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 provide any guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List CloudFlare zones
Args:
per_page: Number of zones per page (5-50)
page: Page number to retrieve
name: Filter by zone name
status: Filter by status (active, pending, initializing, moved, deleted, deactivated)
| Name | Required | Description | Default |
|---|---|---|---|
| per_page | No | ||
| page | No | ||
| name | No | ||
| status | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool lists zones and describes parameters, but it does not disclose any behavioral traits like idempotency, rate limits, or authentication requirements. Since it's a read operation, this is acceptable but minimal.
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?
The description is brief and front-loaded with the purpose. The parameter list is well-structured but could be more compact. No unnecessary sentences.
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 output schema exists, the description sufficiently covers purpose and parameters. However, without annotations, it lacks behavioral context like idempotency or auth, but for a simple list tool, this is largely adequate.
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 0%, so the description fully explains the parameters. It provides clear semantics: per_page range (5-50), page number, name filter, and status filter with enumerated values. This adds significant value beyond the bare schema.
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 'List CloudFlare zones' with a specific verb and resource. It is distinct from sibling tools like cf_get_zone (single zone) and cf_create_zone, ensuring no ambiguity.
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 lists parameters and their purposes, implying when to use this tool (to list zones with filters). However, it lacks explicit guidance on when not to use it or alternatives, such as cf_get_zone for a single zone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Purge CloudFlare cache
Args: zone_id: CloudFlare zone ID purge_everything: Purge all cache (use carefully) files: List of specific URLs to purge tags: List of cache tags to purge hosts: List of hostnames to purge
| Name | Required | Description | Default |
|---|---|---|---|
| zone_id | Yes | ||
| purge_everything | No | ||
| files | No | ||
| tags | No | ||
| hosts | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says 'use carefully' for purge_everything, hinting at destructiveness, but fails to mention rate limits, idempotency, or effects on other Cloudflare actions. This is insufficient.
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?
The description is concise: two sentences plus a bullet list. The main action is front-loaded. The 'Args' format is clear but slightly informal; still effective.
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?
An output schema exists, so return values are covered. However, the description lacks explanation of how each purge method works (e.g., purge_everything invalidates all cache, files/tags/hosts are selective) and does not provide enough context for an agent to choose correctly.
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 description coverage is 0%, so the description carries the burden. It adds meaning beyond the schema: e.g., 'files: List of specific URLs to purge,' 'tags: List of cache tags to purge,' and 'purge_everything: Purge all cache (use carefully).' This clarifies each parameter's role, though it could be more detailed.
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 starts with 'Purge CloudFlare cache', which clearly states the verb (purge) and resource (CloudFlare cache). Among sibling tools like cf_create_dns_record, cf_get_analytics, etc., none are cache-related, so it effectively distinguishes itself.
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 provides no guidance on when to use this tool vs alternatives, nor does it explain when to choose purge_everything over files/tags/hosts. The only hint is 'use carefully' for purge_everything, but there are no explicit use cases or exclusions compared to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a DNS record
Args: zone_id: CloudFlare zone ID record_id: DNS record ID record_type: DNS record type (if changing) name: Record name (if changing) content: Record content (if changing) ttl: Time to live (if changing) proxied: Proxy status (if changing) priority: Priority for MX records (if changing)
| Name | Required | Description | Default |
|---|---|---|---|
| zone_id | Yes | ||
| record_id | Yes | ||
| record_type | No | ||
| name | No | ||
| content | No | ||
| ttl | No | ||
| proxied | No | ||
| priority | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden but only mentions updating. No disclosure of side effects, propagation details, or requirements (e.g., permissions), which is insufficient for a mutation tool.
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?
The description is concise: one sentence plus a parameter list. However, the parameter list largely mirrors the schema, which could be more efficiently 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?
With an output schema, return values need no explanation. The description covers all parameters but misses overall context like when to update vs. create/delete, or authentication requirements. Adequate but not thorough.
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 0%, so the description adds minimal semantics: e.g., 'if changing' notes for optional parameters. This helps but is sparse; for 8 parameters, more detail would be beneficial.
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 'Update a DNS record' clearly states the action and resource. It is distinguishable from sibling tools like cf_create_dns_record and cf_delete_dns_record, though it could explicitly contrast.
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 (e.g., cf_create_dns_record for new records). The description only lists parameters, lacking usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a specific zone setting
Args: zone_id: CloudFlare zone ID setting: Setting name (e.g., 'ssl', 'always_use_https', 'security_level') value: New value for the setting
| Name | Required | Description | Default |
|---|---|---|---|
| zone_id | Yes | ||
| setting | Yes | ||
| value | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully disclose behavior. It only states the update action but omits side effects, permission requirements, or error handling. The simple mutation warrants minimal disclosure but still lacks critical details.
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?
The description is short and to the point, with a clear structure: one sentence followed by argument list. No unnecessary words, though the argument list repeats schema names.
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 output schema exists, return values need not be explained. However, the description lacks context on available settings, value types, and side effects. For a simple tool, it is minimally complete but could be more helpful.
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 description coverage is 0%, so description must add meaning. It provides example values for 'setting' (e.g., 'ssl') but not for 'zone_id' or 'value'. It clarifies the parameter purpose but not valid formats or constraints.
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 tool name and description clearly indicate the action (update) and resource (zone setting). It distinguishes from sibling tools like cf_get_zone_settings (read-only) and cf_create_dns_record (different resource).
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 cf_get_zone_settings. No mention of prerequisites, limitations, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get logs from a Docker container
Args: container_id: Container ID or name tail: Number of lines from end of logs (default: 100) follow: Follow log output (default: False) timestamps: Include timestamps (default: True)
| Name | Required | Description | Default |
|---|---|---|---|
| container_id | Yes | ||
| tail | No | ||
| follow | No | ||
| timestamps | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read operation ('get logs'), but does not explicitly state it is non-destructive or safe. With no annotations, the agent must infer this from the verb. It does disclose default parameter behaviors, which adds some 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?
The description is concise with a single-line purpose followed by a clear parameter list. It is front-loaded and efficiently uses space, though a brief note on behavior could be added without bloat.
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 log retrieval tool, the description covers all parameters and the core operation. The presence of an output schema reduces the need to describe return values. Missing: error handling or performance notes, but generally adequate.
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?
The input schema has 0% description coverage, but the tool description documents all four parameters, explaining their purpose (e.g., 'tail' is number of lines from end, 'follow' to follow output). This adds meaning beyond the schema's type and default values.
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 logs from a Docker container, which distinguishes it from sibling tools that manage containers, images, or DNS records. The verb 'get' and resource 'logs' make the purpose explicit.
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 is provided on when to use this tool versus alternatives like docker_list_containers or docker_system_info. There is no mention of prerequisites (e.g., container must exist) or conditions under which logs are available.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Docker containers
Args: all_containers: Include stopped containers (default: True) filters: Optional filters {"key": "value"}
| Name | Required | Description | Default |
|---|---|---|---|
| all_containers | No | ||
| filters | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits beyond listing. It does not mention default behavior (e.g., all_containers default is True, so it includes stopped containers) or any side effects.
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?
The description is minimal and front-loaded with the purpose. Two concise lines for parameters, no redundant information.
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 and the presence of an output schema, the description covers the essentials. It could mention default listing behavior (all vs. running), but overall adequate.
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 description coverage is 0%, but the description adds meaning for both parameters: 'Include stopped containers (default: True)' and 'Optional filters {"key": "value"}'. This compensates for the lack of schema descriptions, though filter format could be more explicit.
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 'List Docker containers' is a specific verb+resource pair. It clearly distinguishes from sibling tools like docker_get_logs, docker_list_images, etc., as listing containers is a distinct operation.
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 only outlines parameters, not when to use this tool over alternatives. No guidance on context, exclusions, 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.
List Docker images
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states the action without any behavioral details. Since no annotations are provided, the description carries full burden but fails to disclose that this is a safe read operation, what side effects (none) exist, or any permission requirements. It lacks transparency beyond the bare minimum.
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?
The description is a single sentence with no extraneous words. It is front-loaded and earns its place without any padding. Perfect conciseness for a trivial tool.
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 has no parameters and an output schema exists, the description could be more informative by mentioning what the output contains (e.g., image names, tags). However, for a simple list operation, 'List Docker images' is minimally viable but lacks completeness that an agent might benefit from.
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?
The input schema has no parameters and 100% coverage, so the baseline is 3. The description adds no parameter-level information because there are none. It does not provide any additional semantics that the schema does not already cover.
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 'List Docker images' clearly states the verb (list) and resource (Docker images), making the tool's purpose immediately obvious. It distinguishes itself from siblings like docker_list_containers and docker_run_container by focusing specifically on images.
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 is provided on when to use this tool versus alternatives. For example, it does not mention that this is a read-only operation or that it lists all local images without filtering. Siblings like docker_pull_image or docker_run_container have different use cases, but the description offers 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.
Pull a Docker image
Args: image: Image name to pull (e.g., 'nginx:latest') registry: Registry server URL (optional, defaults to Docker Hub) use_auth: Whether to use authentication (default: True)
| Name | Required | Description | Default |
|---|---|---|---|
| image | Yes | ||
| registry | No | ||
| use_auth | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must fully disclose behavior. It mentions authentication but does not describe side effects (e.g., overwriting existing images), progress, or failure modes. For a mutation tool, this is insufficient.
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?
Concise and front-loaded with purpose. Uses an args-style list which is clear, though could be more structured (e.g., bullet points). No unnecessary information.
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?
Output schema exists (not shown), so return values need not be detailed. However, for a pull operation, additional context like layer download handling or authentication failure behavior would improve completeness. Adequate for a simple 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 description coverage is 0%, but the description adds meaning: provides an example for image, notes registry defaults to Docker Hub, and explains use_auth defaults to True. This compensates well for missing schema descriptions.
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 states 'Pull a Docker image', which is clear and specific. It distinguishes from sibling tools like docker_list_images or docker_run_container. However, 'pull' could be further elaborated to clarify it downloads image layers.
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 docker_run_container (which pulls if missing). No mention of prerequisites or context, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a Docker container
Args: container_id: Container ID or name force: Force remove running container
| Name | Required | Description | Default |
|---|---|---|---|
| container_id | Yes | ||
| force | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks behavioral details. It does not explain that removing a container destroys it, or that force is needed for running containers. Given no annotations, this is insufficient.
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?
The description is concise, with parameters listed after the main action. Every sentence adds value.
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?
The description covers the basic purpose and parameters, but for a removal tool, it lacks context on consequences, failure modes, or return values. The presence of an output schema somewhat mitigates, but overall completeness is adequate but not comprehensive.
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?
With 0% schema coverage, the description compensates by explaining each parameter's purpose. It clarifies that container_id can be ID or name, and force allows removal of running containers. This is sufficient but not exhaustive.
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 (remove) and resource (Docker container). It distinguishes from sibling tools like docker_stop_container which stops but does not remove.
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 usage guidelines are provided. The description does not indicate when to use this tool over alternatives like docker_stop_container, nor does it mention prerequisites or side effects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a Docker container with specified configuration
Args: image: Docker image name (e.g., 'nginx:latest') name: Optional container name command: Optional command to run ports: Optional port mappings {"container_port": host_port} environment: Optional environment variables volumes: Optional volume mounts {"host_path": "container_path"} detach: Run in detached mode (default: True) remove: Remove container when it stops (default: False)
| Name | Required | Description | Default |
|---|---|---|---|
| image | Yes | ||
| name | No | ||
| command | No | ||
| ports | No | ||
| environment | No | ||
| volumes | No | ||
| detach | No | ||
| remove | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description reveals key behaviors: defaults for detach and remove, port/volume mapping formats. However, it does not mention side effects like auto-pulling images, error handling, or what happens on success. No annotations were provided to supplement.
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?
Main sentence is front-loaded, and parameters are listed as a bulleted 'Args' block. While efficient, it is slightly verbose for a run tool. Each line is short and relevant.
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?
Input side is well-covered, but the description lacks information about output/return values despite an output schema existing. No mention of container ID, status, or error behavior. The description is incomplete for a run operation with many optional parameters.
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?
With 0% schema description coverage, the description compensates fully by explaining each parameter's purpose and expected format (e.g., 'Optional port mappings {"container_port": host_port}'). All 8 parameters are described clearly.
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 'Run a Docker container' with specific verb and resource. It lists all configuration parameters and is easily distinguished from sibling tools like docker_list_containers or docker_remove_container.
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?
Usage is implied by the description (to run a new container), but no explicit guidance on when to use this vs alternatives like docker_start_container or docker_pull_image. No when-not or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a stopped Docker container
Args: container_id: Container ID or name
| Name | Required | Description | Default |
|---|---|---|---|
| container_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It only states the core action without disclosing side effects (e.g., error if container already running), permissions needed, or return value information, despite an output schema existing.
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?
The description is extremely concise: one sentence for purpose and one line for the parameter. No redundant words or padding.
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 low complexity (1 parameter, no annotations, output schema present), the description is too sparse. It fails to mention typical return format, error cases, or state dependencies, leaving gaps for an AI 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?
The description for the lone parameter, 'container_id: Container ID or name', adds clarity by specifying that it accepts both ID and name, which the schema lacks (schema description coverage 0%). This expands on the schema.
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 'Start a stopped Docker container', using specific verb and resource, and implies the container must be stopped, which distinguishes it from related tools like docker_stop_container.
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 versus alternatives, nor any prerequisites or conditions. The description implies it is for stopped containers, but does not state when not to use it or how to verify state.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop a Docker container
Args: container_id: Container ID or name timeout: Timeout in seconds before forcefully killing
| Name | Required | Description | Default |
|---|---|---|---|
| container_id | Yes | ||
| timeout | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Mentions timeout for forceful killing, but does not disclose behavioral traits like what happens on success, if container already stopped, or effects on attached processes. No annotations are present.
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?
Extremely concise: two sentences plus an Args block. No wasted words; every part contributes to clarity.
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?
Adequate for a simple stop action, but lacks details on output or edge cases. Given the presence of an output schema, the description does not need to explain return values, but could mention transition to stopped state.
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?
With 0% schema description coverage, the description adds meaning beyond the schema: container_id is 'Container ID or name' and timeout is 'seconds before forcefully killing'. This is helpful for an agent.
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 'Stop a Docker container', using a specific verb and resource. It distinguishes itself from siblings like docker_remove_container (which removes) and docker_start_container (which starts).
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 docker_remove_container or docker_kill. The description lacks context for appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Docker system information
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided; the description only states it is a read operation but gives no details about required permissions, data volume, or other behavioral traits.
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?
The description is a single, efficient sentence with 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?
The description is minimal but acceptable given the presence of an output schema; however, it could mention what system information is returned.
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 no parameters, so the schema coverage is effectively 100%; the baseline of 4 is appropriate as the description adds no parameter information.
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 'Get Docker system information' clearly states the verb and resource, and it distinguishes from sibling tools as it is the only one for system info.
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; the description lacks any context about appropriate use cases.
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.
v1.0.0cf_create_dns_recordcf_create_zonecf_delete_dns_recordcf_delete_zonecf_get_analyticscf_get_zonecf_get_zone_settingscf_list_dns_recordscf_list_zonescf_purge_cachecf_update_dns_recordcf_update_zone_settingdocker_get_logsdocker_list_containersdocker_list_imagesdocker_pull_imagedocker_remove_containerdocker_run_containerdocker_start_containerdocker_stop_containerdocker_system_infoScored across 21 tools
Tools are clearly disambiguated by their 'cf_' and 'docker_' prefixes, making it easy to distinguish between CloudFlare and Docker operations. However, the presence of two unrelated domains may confuse an agent about which set to use for a given task.
All tool names follow a consistent pattern: prefix (cf_ or docker_) followed by verb_noun (e.g., cf_create_dns_record, docker_list_containers). No style mixing or vague verbs observed.
21 tools is on the high side for a typical single-purpose server, though each subdomain (CloudFlare and Docker) has a reasonable count. The combined set feels heavy and could be split into separate servers for better coherence.
The CloudFlare tools cover core zone and DNS operations, while Docker tools cover basic container lifecycle. However, both lack advanced features (e.g., Docker networks, CloudFlare firewall rules), and the dual-domain focus leaves potential gaps in each area.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
Devopness MCP server for DevOps happiness! Empower AI Agents to deploy apps and infra, to any cloud.
