EasyPanel MCP Server

Overview Schema Source Related Servers Discussions Admin

scale_service

Idempotent

Adjust a service's CPU and memory limits to handle changing demand. Provide the service ID and new resource values to match capacity with workload needs.

Instructions

Vertically scale a service's resources.

Args: service_id: Service ID cpu: New CPU limit (cores) memory: New memory limit (MB)

Tool call template

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

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "service_id": "<service_id>"
    },
    "name": "scale_service"
  }
}

Input Schema

Name	Required	Description	Default
`cpu`	No
`memory`	No
`service_id`	Yes

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv2.0.0Sep 5, 2026

TDQS

B3.4/5.0

Behavior2/5

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

With only idempotentHint annotated, the description carries the burden of behavioral disclosure but adds no side-effect context. It doesn't mention whether scaling causes downtime, a restart, or how changes are applied, leaving an agent to guess operational impact.

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

Conciseness4/5

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

Front-loaded with a clear action sentence followed by a compact Args list. No wasted words, though the Args section lightly duplicates schema property titles without adding much beyond units.

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

Completeness3/5

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

The description covers the basic operation and parameters, and an output schema exists, so return values aren't needed. However, it omits null-value semantics and fails to differentiate from auto_scale_service, leaving a moderate gap for a mutation tool.

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

Parameters4/5

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

Schema description coverage is 0%, so the description compensates by explaining cpu and memory with units (cores, MB) and identifying service_id. It adds meaningful semantics beyond the bare schema, though it does not clarify null/default behavior.

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

Purpose5/5

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

States a specific verb ('vertically scale') and resource ('service's resources'), clearly distinguishing it from siblings like auto_scale_service and restart_service. The purpose is immediately understandable and unambiguous.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus closely related siblings such as auto_scale_service, update_service, or restart_service. The description provides no context for selection or exclusion.

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