MCP server for managing Cloud.ru Container Apps, Docker operations, artifact registries, and jobs
This server has 20 tools with reasonably consistent naming patterns (all prefixed with 'cloudru_' and using clear action verbs like get, create, delete, list, patch). However, there are significant gaps in parameter descriptions, schema completeness, and error handling. Most tools have descriptions (10-15 lines typically), but parameters frequently lack detailed constraints, format requirements, and actionable validation guidance. Output schemas are not documented in the visible code. Several tools combine related concerns (e.g., cloudru_docker_build_and_push combines build AND push). Parameter descriptions are generic (e.g., 'Port the container runs on' with no min/max). No evidence of enum constraints, dependency documentation, or error recovery guidance. The rubric baseline for A+ tools requires 100% of params to have descriptions and documented output schemas, this server achieves ~60% param description coverage with sparse schema documentation.
Create a new Container App in Cloud.ru
Create a new Docker registry in Cloud.ru
Create a new job in Cloud.ru
Delete a Container App from Cloud.ru. WARNING: This action cannot be undone!
Delete a job from Cloud.ru
Get the application description
Build and push a Docker image to a registry
Output schemas not documented. No visible schema definitions for tool responses, LLMs cannot plan downstream tool calls or extract required fields for chaining.
Parameters lack format constraints and ranges. Examples: 'containerapp_port' (integer) has no min/max bounds; 'containerapp_cpu' (string) has no format hint; 'containerapp_idle_timeout' and 'containerapp_timeout' have no pattern or example. LLMs cannot validate inputs without these constraints.
cloudru_docker_build_and_push combines two distinct operations (build AND push) in a single tool name. This violates single responsibility, should be split into cloudru_docker_build and cloudru_docker_push so agents can compose them independently.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 41 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 43 | - | v1 |
Authenticate with a Docker registry
Execute a job in Cloud.ru
Get a specific Container App from Cloud.ru by name. Project ID can be set via PROJECT_ID environment variable and obtained from console.cloud.ru
Get logs for a specific Container App from Cloud.ru by name. Project ID can be set via PROJECT_ID environment variable and obtained from console.cloud.ru
Get details of a specific job
List all Container Apps in a Cloud.ru project
List all Docker registries in a Cloud.ru project
List all executions of a specific job
List all jobs in a Cloud.ru project
Update an existing Container App in Cloud.ru
Update an existing job in Cloud.ru
Start a Container App in Cloud.ru
Stop a Container App in Cloud.ru
No enum constraints on string parameters. cloudru_create_containerapp accepts 'containerapp_protocol' (http_1, http_2, etc.) and 'containerapp_auto_deployments_pattern' as free-form strings with no enum or validation. LLMs will hallucinate invalid values.
Missing error handling guidance. No evidence of recovery hints (e.g., 'if container not found, try cloudru_list_containerapps first'), retryable vs. fatal classifications, or actionable error messages in tool responses.
No pagination guidance for list tools. cloudru_list_containerapps, cloudru_list_docker_registries, cloudru_list_jobs, and cloudru_list_executions have no page/offset/limit parameters visible. If APIs return hundreds of items, results will blow context windows.
Destructive operations lack confirmation patterns. cloudru_delete_containerapp and cloudru_delete_job are marked DESTRUCTIVE but have no dry-run, confirmation request, or undo capability. Agents can accidentally delete resources.
Parameter descriptions are generic and lack actionable constraints. Examples: 'Port the container runs on' (no valid range); 'CPU allocation' (no units or examples like '0.5', '1', '2'); 'Enable automatic deployments' (no explanation of when/why to use). Rubric baseline: param annotations should average 72+ chars with format/constraint details.
No idempotency guarantees documented. cloudru_create_containerapp, cloudru_create_docker_registry, and cloudru_create_job do not state whether repeated calls with same input are safe (idempotent) or risk duplicates. Agents retry on ambiguous failures, non-idempotent tools cause double-creation.
Tool-to-tool chaining data missing. If cloudru_list_containerapps returns container names but cloudru_get_containerapp requires 'containerapp_name' as input, the response must explicitly include the 'containerapp_name' field for the agent to chain. Output schema visibility is required.