Skip to main content
Glama

rename_device

Change the friendly name of a WeMo smart home device to update how it appears in the WeMo app and for identification. Provide the device's current name or IP address and specify the new name.

Instructions

Rename a WeMo device (change its friendly name).

Changes the friendly name of a WeMo device. This is the name that appears in the WeMo app and is used to identify the device. The device must have been discovered via scan_network first.

After renaming, the device cache will be updated with the new name. You may want to run scan_network again to refresh the device list.

Args:

device_identifier: Current device name (e.g., "Office Dimmer") or IP address (e.g., "192.168.1.100")
new_name: New friendly name for the device (e.g., "Office Light")

Returns:

Dictionary containing:
- success: Boolean indicating if the rename succeeded
- old_name: The previous name of the device
- new_name: The new name of the device
- device_ip: IP address of the device

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
device_identifierYes
new_nameYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • The rename_device function handles the logic for renaming a WeMo device. It validates inputs, ensures the device is accessible via cache, performs the actual rename operation using pywemo's rename methods, and updates the cache.
    async def rename_device(device_identifier: str, new_name: str) -> dict[str, Any]:
        """Rename a WeMo device (change its friendly name).
    
        Changes the friendly name of a WeMo device. This is the name that appears
        in the WeMo app and is used to identify the device. The device must have
        been discovered via scan_network first.
    
        After renaming, the device cache will be updated with the new name. You may
        want to run scan_network again to refresh the device list.
    
        Args:
        ----
            device_identifier: Current device name (e.g., "Office Dimmer") or IP address (e.g., "192.168.1.100")
            new_name: New friendly name for the device (e.g., "Office Light")
    
        Returns:
        -------
            Dictionary containing:
            - success: Boolean indicating if the rename succeeded
            - old_name: The previous name of the device
            - new_name: The new name of the device
            - device_ip: IP address of the device
    
        """
        # Validate inputs
        try:
            params = RenameDeviceParams(
                device_identifier=device_identifier,
                new_name=new_name,
            )
        except ValidationError as e:
            return {
                "error": ERR_INVALID_PARAMS,
                "validation_errors": [
                    {"field": err["loc"][0], "message": err["msg"], "input": err["input"]}
                    for err in e.errors()
                ],
                "success": False,
            }
    
        try:
            # Try to find device in memory cache, then reconnect from file cache if needed
            device = _device_cache.get(params.device_identifier)
            if not device:
                device = await _reconnect_device_from_cache(params.device_identifier)
    
            if not device:
                return {
                    "error": f"Device '{params.device_identifier}' not found in cache",
                    "suggestion": ERR_RUN_SCAN_FIRST,
                    "available_devices": [
                        k
                        for k in _device_cache
                        if isinstance(k, str) and not k.replace(".", "").isdigit()
                    ],
                    "success": False,
                }
    
            old_name = device.name
            device_ip = getattr(device, "host", "unknown")
    
            # Perform the rename operation in a thread pool
            loop = asyncio.get_event_loop()
    
            # Try both methods for compatibility with different pywemo versions
            def rename_operation():
                if hasattr(device, "change_friendly_name"):
                    device.change_friendly_name(params.new_name)
                elif hasattr(device, "basicevent"):
                    device.basicevent.ChangeFriendlyName(FriendlyName=params.new_name)
                else:
                    raise AttributeError("Device does not support renaming")
    
            await loop.run_in_executor(None, rename_operation)
    
            # Wait a moment for the device to respond
            await asyncio.sleep(0.5)
    
            # Update the cache with the new name
            # Remove old name entry and add new one
            _device_cache.pop(old_name, None)
            _device_cache[params.new_name] = device
    
            # Also update IP-based cache entry if it exists
            if device_ip in _device_cache:
                _device_cache[device_ip] = device
    
            result = {
                "success": True,
                "old_name": old_name,
                "new_name": params.new_name,
                "device_ip": device_ip,
                "message": f"Device renamed from '{old_name}' to '{params.new_name}'",
                "timestamp": time.time(),
            }
    
            logger.info(f"Device renamed: '{old_name}' -> '{params.new_name}' at {device_ip}")
            return result
    
        except Exception as e:
            logger.error(f"Error renaming device: {e}", exc_info=True)
            return build_error_response(
                e,
                "Rename device",
                context={
                    "device_identifier": device_identifier,
                    "new_name": new_name,
                },
            )
Behavior4/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 effectively describes several behavioral traits: that this is a mutation operation (changes the friendly name), that it requires device discovery first, that it updates the device cache, and that a follow-up scan might be needed. It doesn't mention authentication requirements, rate limits, or error conditions, but covers the core behavioral aspects well.

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

Conciseness5/5

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

The description is well-structured and appropriately sized. It starts with a clear purpose statement, provides necessary context about prerequisites and consequences, then documents parameters and return values in a structured format. Every sentence serves a clear purpose with zero waste.

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

Completeness5/5

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

Given this is a mutation tool with no annotations but with an output schema (implied by the Returns section), the description provides excellent completeness. It covers purpose, prerequisites, behavioral consequences, parameter semantics, and return values. The output schema in the description eliminates the need for separate structured output documentation.

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

Parameters5/5

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

With 0% schema description coverage, the description fully compensates by providing detailed parameter semantics. It explains that 'device_identifier' can be either the current device name or IP address with concrete examples, and that 'new_name' is the new friendly name for the device. This adds substantial value beyond the bare schema.

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?

The description clearly states the specific action ('Rename a WeMo device'), the resource ('WeMo device'), and the scope ('change its friendly name'). It distinguishes this from sibling tools like 'list_devices' or 'control_device' by focusing specifically on renaming rather than listing or controlling.

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

Usage Guidelines4/5

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

The description provides clear context about when to use this tool: 'The device must have been discovered via scan_network first.' It also suggests a follow-up action: 'You may want to run scan_network again to refresh the device list.' However, it doesn't explicitly state when NOT to use this tool or name specific alternatives among siblings.

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/apiarya/wemo-mcp-server'

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