Skip to main content
Glama

set_charging

Control robot vacuum charging by sending it to the charging station or stopping the return process using the Ecovacs MCP Server.

Instructions

Make robot return to charging station

Args: nickname: Robot nickname, used to find device act: Robot action, go-start begin returning to charging station, stopGo stop returning to charging station

Returns: Dict: Dictionary containing execution results

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nicknameYesRobot nickname, used to find device
actNoRobot action, go-start begin returning to charging station, stopGo stop returning to charging stationgo-start

Implementation Reference

  • The handler function for the 'set_charging' tool, decorated with @mcp.tool() for registration. It takes nickname and act parameters, validates with Pydantic Fields (schema), and calls the shared API helper with 'Charge' command.
    @mcp.tool()
    async def set_charging(
        nickname: str = Field(description="Robot nickname, used to find device"),
        act: str = Field(description="Robot action, go-start begin returning to charging station, stopGo stop returning to charging station", default="go-start")
    ) -> dict:
        """
        Make robot return to charging station
        
        Args:
            nickname: Robot nickname, used to find device
            act: Robot action, go-start begin returning to charging station, stopGo stop returning to charging station
        
        Returns:
            Dict: Dictionary containing execution results
        """
        return await call_api(ENDPOINT_ROBOT_CTL, {"nickName": nickname, "cmd": "Charge", "act": act})
  • Shared helper function used by set_charging to make HTTP API calls to the Ecovacs API.
    async def call_api(endpoint: str, params: dict, method: str = 'post') -> dict:
        """
        General API call function
        
        Args:
            endpoint: API endpoint
            params: Request parameters
            method: Request method, 'get' or 'post'
        
        Returns:
            Dict: API response result, format {"msg": "OK", "code": 0, "data": [...]}
        """
        # Build complete URL
        url = f"{API_URL}/{endpoint}"
        
        # Ensure all parameters are strings
        params = {k: str(v) for k, v in params.items()}
        
        # Add API key
        if API_KEY:
            params.update({"ak": API_KEY})
        
        try:
            async with httpx.AsyncClient() as client:
                headers = {"Content-Type": "application/json"}
                if method.lower() == 'get':
                    response = await client.get(url, params=params, timeout=REQUEST_TIMEOUT)
                else:
                    response = await client.post(url, json=params, headers=headers, timeout=REQUEST_TIMEOUT)
                
                response.raise_for_status()
                return response.json()
        
        except Exception as e:
            # Return unified error format when an error occurs
            return {"msg": f"Request failed: {str(e)}", "code": -1, "data": []}
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the robot action types but doesn't cover important aspects like whether this requires specific permissions, what happens if the robot is already charging, whether the action is reversible, or potential error conditions. The return value description ('Dictionary containing execution results') is too vague.

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

Conciseness4/5

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

The description is appropriately brief with a clear purpose statement followed by structured Args and Returns sections. However, the parameter descriptions in the Args section are redundant with the schema and could be more concise. The overall structure is logical and front-loaded.

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

Completeness2/5

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

For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the execution results dictionary contains, what success/failure looks like, or important behavioral constraints. Given the complexity of controlling physical robot behavior, more context about limitations, safety considerations, or state dependencies would be needed.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents both parameters completely. The description repeats the parameter information verbatim without adding any additional context, syntax examples, or format details beyond what the schema provides. This meets the baseline for high schema coverage.

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

Purpose4/5

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

The description clearly states the action ('Make robot return to charging station') and identifies the resource (robot). It distinguishes from sibling tools like 'set_cleaning' by focusing on charging behavior rather than cleaning. However, it doesn't explicitly contrast with 'get_device_list' or 'get_work_state' which are read-only operations.

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

Usage Guidelines3/5

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

The description implies usage through the parameter descriptions ('go-start begin returning', 'stopGo stop returning'), suggesting when to use different actions. However, it doesn't provide explicit guidance on when to choose this tool over alternatives like 'set_cleaning' or mention prerequisites such as robot availability.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

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

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

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