Skip to main content
Glama
sealablab

Moku MCP Server

by sealablab

set_routing

Configure MCC signal routing connections to direct signals between specified sources and destinations in Moku devices.

Instructions

Configure MCC signal routing

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
connectionsYesList of routing connections

Implementation Reference

  • The handler implementation for the set_routing MCP tool which validates and applies signal routing connections to a Moku device.
    async def set_routing(self, connections: list):
        """
        Configure MCC signal routing.
    
        Args:
            connections: List of {"source": "...", "destination": "..."} dicts
    
        Returns:
            {
                "status": "configured",
                "connections_count": 2
            }
    
        Implementation: See IMPLEMENTATION_GUIDE.md Section 3.6
        """
        from moku_models import MokuConnection
        from pydantic import ValidationError
    
        if not self.moku_instance:
            return {
                "status": "error",
                "message": "Not connected to any device",
                "suggestion": "Call attach_moku first",
            }
    
        # Validate connections
        try:
            parsed_connections = [MokuConnection(**conn) for conn in connections]
        except ValidationError as e:
            logger.error(f"Invalid connection format: {e}")
            return {
                "status": "error",
                "message": "Invalid connection format",
                "errors": e.errors(),
            }
    
        # Apply to hardware
        try:
            self.moku_instance.set_connections(connections)
            logger.info(f"Configured {len(connections)} routing connections")
    
            # Update cached config if we have one
            if self.last_config:
                self.last_config.routing = parsed_connections
    
            return {"status": "configured", "connections_count": len(connections)}
    
        except Exception as e:
            logger.error(f"Failed to configure routing: {e}")
            return {
                "status": "error",
                "message": "Failed to configure routing",
                "details": str(e),
            }
Behavior1/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 but provides none. It does not indicate whether this operation is destructive (overwrites existing routes), idempotent, requires specific privileges, or what errors might occur (e.g., invalid source/destination validation).

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

Conciseness2/5

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

While the three-word description contains no filler, it is inappropriately undersized for a configuration tool handling signal routing. It fails the test that 'every sentence should earn its place' because it provides insufficient information to justify its brevity given the operational complexity implied by the schema.

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

Completeness1/5

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

Given the lack of output schema, annotations, and the write-operation nature of 'set' commands, the description is grossly incomplete. It omits critical context such as whether changes are immediate, if they persist across reboots, or what the MCC context refers to, leaving the agent unprepared to invoke the tool correctly.

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?

The input schema has 100% description coverage ('List of routing connections'), establishing a baseline of 3. The description adds no further semantics about what constitutes valid 'source' or 'destination' strings (e.g., hardware channels, logical identifiers), nor does it explain the MCC routing domain, but it does not need to compensate for schema gaps since coverage is complete.

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

Purpose2/5

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

The description 'Configure MCC signal routing' is essentially a tautology that restates the tool name 'set_routing' with minimal expansion. While it mentions 'MCC' (undefined acronym) and 'signal routing', it fails to distinguish this tool from siblings like 'push_config' or 'get_config', leaving the specific scope ambiguous.

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

Usage Guidelines1/5

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

No usage guidance is provided. The description does not indicate when to use this tool versus alternatives like 'push_config', nor does it mention prerequisites (e.g., whether a device must be attached first) or warn about potential disruption to existing signals when re-routing.

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/sealablab/moku-mcp'

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