Skip to main content
Glama
danroblewis

G1 UART MCP Server

by danroblewis

scan_g1_devices

Scan for available G1 Bluetooth devices to discover and list them with addresses and signal strength for connection setup.

Instructions

Scan for available G1 devices.

Returns:
    Dict[str, Any]: JSON response with scan results including:
        - result: "success" or "error"
        - devices: List of discovered devices with their properties
        - count: Number of devices found
        - error: Error message if scan failed
    
Note:
    This performs an actual BLE scan for devices with names containing "G1_" pattern.
    Returns a structured list of discovered devices with their addresses and signal strength.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • Handler function for scan_g1_devices tool. Decorated with @server.tool() for registration. Performs BLE scan using NordicBLEUARTManager, processes devices to identify left/right G1 devices, and returns structured JSON result.
    async def scan_g1_devices() -> Dict[str, Any]:
        """Scan for available G1 devices.
        
        Returns:
            Dict[str, Any]: JSON response with scan results including:
                - result: "success" or "error"
                - devices: List of discovered devices with their properties
                - count: Number of devices found
                - error: Error message if scan failed
            
        Note:
            This performs an actual BLE scan for devices with names containing "G1_" pattern.
            Returns a structured list of discovered devices with their addresses and signal strength.
        """
        try:
            devices = await ble_manager.scan_for_devices(filter_pattern="G1_")
        except Exception as e:
            logger.error(f"Scan failed: {e}")
            return {
                "result": "error",
                "error": str(e),
                "devices": [],
                "count": 0
            }
        
        # Process devices to extract side information and format properly
        processed_devices = []
        for device in devices:
            device_info = {
                "name": device['name'],
                "id": device['address'],
                "side": "right" if "_R_" in device['name'] else "left" if "_L_" in device['name'] else "unknown",
                "rssi": device.get('rssi') if device.get('rssi') != 'N/A' else None
            }
            processed_devices.append(device_info)
        
        return {
            "result": "success",
            "devices": processed_devices,
            "count": len(processed_devices)
        }
  • mcp_server.py:74-74 (registration)
    The @server.tool() decorator registers the scan_g1_devices function as an MCP tool with the FastMCP server.
    async def scan_g1_devices() -> Dict[str, Any]:
  • Helper function that uses the same scan_for_devices logic to find and auto-connect to right G1 devices.
    async def auto_connect_to_right_device():
        """Automatically scan for and connect to the first right G1 device found"""
        try:
            logger.info("Auto-connecting to right G1 device...")
            
            # Scan for devices
            devices = await ble_manager.scan_for_devices(filter_pattern="G1_")
            
            if not devices:
                logger.warning("No G1 devices found during auto-connect")
                return False
            
            # Find the first device with "_R_" in the name (right device)
            right_device = None
            for device in devices:
                if "_R_" in device['name']:
                    right_device = device
                    break
            
            if not right_device:
                logger.warning("No right G1 device found during auto-connect")
                return False
            
            logger.info(f"Found right G1 device: {right_device['name']} ({right_device['address']})")
            
            # Attempt to connect
            success = await ble_manager.connect_to_device(right_device['address'])
            
            if success:
                logger.info(f"Auto-connect successful to {right_device['name']}")
                return True
            else:
                logger.warning(f"Auto-connect failed to {right_device['name']}")
                return False
                
        except Exception as e:
            logger.error(f"Auto-connect failed: {e}")
            return False
Behavior4/5

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

No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: it performs a BLE scan (implying it may take time and consume resources), returns structured results including success/error status and device properties, and specifies the device name pattern 'G1_'. It doesn't mention rate limits, auth needs, or destructive effects, but for a scan tool, this is reasonably transparent given the lack of annotations.

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 appropriately sized and well-structured: it starts with a clear purpose statement, then details the return format in a bulleted list, and adds a note with behavioral context. Every sentence adds value, with no wasted words, and it's front-loaded with the main action.

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 the tool's low complexity (0 parameters), lack of annotations, and presence of an output schema (implied by the return description), the description is complete enough. It explains what the tool does, the return structure, and key behavioral aspects like the BLE scan and device pattern. No output schema is explicitly provided, but the return description compensates adequately.

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?

The input schema has 0 parameters with 100% coverage, so no parameters need documentation. The description doesn't add param info, which is fine here. Baseline is 4 for 0 parameters, as it doesn't need to compensate for any gaps.

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 tool's purpose: 'Scan for available G1 devices.' It specifies the verb ('Scan') and resource ('G1 devices'), and the note adds that it performs a BLE scan for devices with names containing 'G1_'. However, it doesn't explicitly differentiate from sibling tools like 'connect_g1_device' or 'get_g1_connection_status' beyond the scanning action.

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 by stating it 'performs an actual BLE scan for devices with names containing "G1_" pattern,' which suggests when to use it (to discover G1 devices). However, it doesn't provide explicit guidance on when not to use it or mention alternatives like checking connection status with sibling tools. The context is clear but lacks exclusions or named alternatives.

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/danroblewis/g1_uart_mcp'

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