Skip to main content
Glama

set_cleaning

Control Ecovacs robot vacuum cleaning operations: start, pause, resume, or stop cleaning cycles using robot nickname and action codes.

Instructions

Start robot cleaning

Args: nickname: Robot nickname, used to find device act: Cleaning action s-start cleaning, r-resume cleaning, p-pause cleaning, h-stop cleaning Returns: Dict: Dictionary containing execution results

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nicknameNoRobot nickname, supports fuzzy matching
actNoCleaning action, s-start cleaning, r-resume cleaning, p-pause cleaning, h-stop cleanings

Implementation Reference

  • Registers the set_cleaning tool using the @mcp.tool() decorator.
    @mcp.tool()
  • The main handler function implementing the set_cleaning tool logic. It calls the API with the 'Clean' command and the specified action (start, resume, pause, stop).
    async def set_cleaning(
        nickname: str = Field(description="Robot nickname, supports fuzzy matching", default=""),
        act: str = Field(description="Cleaning action, s-start cleaning, r-resume cleaning, p-pause cleaning, h-stop cleaning", default="s")
    ) -> dict:
        """
        Start robot cleaning
        
        Args:
            nickname: Robot nickname, used to find device
            act: Cleaning action s-start cleaning, r-resume cleaning, p-pause cleaning, h-stop cleaning
        Returns:
            Dict: Dictionary containing execution results
        """
        return await call_api(ENDPOINT_ROBOT_CTL, {"nickName": nickname, "cmd": "Clean", "act": act})
  • Input schema definitions using Pydantic Field for the nickname and act parameters.
    nickname: str = Field(description="Robot nickname, supports fuzzy matching", default=""),
    act: str = Field(description="Cleaning action, s-start cleaning, r-resume cleaning, p-pause cleaning, h-stop cleaning", default="s")
  • Helper function for making API calls to the Ecovacs service, used by set_cleaning.
    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": []}
  • Constant defining the API endpoint for robot control operations.
    ENDPOINT_ROBOT_CTL = "robot/ctl"
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the action types (start, resume, pause, stop) but lacks critical details such as required permissions, error conditions, or side effects (e.g., whether the robot moves immediately). This is insufficient for a mutation tool with zero annotation coverage.

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 sized and front-loaded with the main purpose. The structured 'Args' and 'Returns' sections are clear, though the formatting could be slightly more polished (e.g., using bullet points). Overall, it's efficient with little waste.

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?

Given the complexity of controlling a robot (a mutation tool with no annotations and no output schema), the description is incomplete. It lacks information on return values (only states 'Dict' without details), error handling, and how it integrates with sibling tools, leaving significant gaps for the agent.

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 fully. The description adds minimal value by restating the 'act' parameter's options in a slightly different format but doesn't provide additional context like examples or edge cases beyond what the schema specifies.

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 ('Start robot cleaning') and resource (robot), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'set_charging' or 'get_work_state', which would require a more specific comparison to achieve a perfect score.

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 is provided on when to use this tool versus alternatives. For example, it doesn't mention prerequisites like needing a robot device from 'get_device_list' or how it relates to checking status with 'get_work_state'. This leaves the agent without context for tool selection.

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