Skip to main content
Glama
Buggy1111

shelly-mcp

by Buggy1111
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Related Servers

Alternatives to shelly-mcp

No user-submitted related servers found.

    Related Servers

    • mcp-tahoma

      pierresouchay
      F
      license
      Not graded
      quality
      C
      maintenance
      MCP server for controlling Somfy TaHoma devices locally via the box's API, without cloud dependency.
      -

    • hass-mcp-server

      jarahkon
      A
      license
      B
      quality
      C
      maintenance
      MCP server for full Home Assistant control, enabling AI agents to manage dashboards, automations, files, apps, entities, and more via REST API, WebSocket, and SSH.
      66
      170 npm
      MIT

    • Hubitat MCP Server

      solaegis
      A
      license
      A
      quality
      D
      maintenance
      MCP server for Hubitat Elevation hubs that controls devices via the Maker API, with optional gated access to undocumented admin routes, supporting device listing, command sending, virtual device and hub variable automation for Rule Machine, and hub management features.
      8
      MIT

    • govee-mcp

      evefromwayback
      A
      license
      Not graded
      quality
      D
      maintenance
      A LAN-first, cloud-fallback MCP server for controlling Govee smart devices by name. It enables AI agents or MCP clients to manage lights, plugs, and appliances with commands like power, brightness, color, and scenes.
      44 PyPI
      MIT
    Deploy Server
    One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

    TDQS

    A3.5/5.0

    Scored across 47 tools

    Disambiguation4/5

    Almost every tool has a distinct resource+action target, and descriptions sharply differentiate read vs. write (shelly_rpc vs shelly_rpc_write) and info vs. status vs. config. The only real overlap is shelly_list_devices vs shelly_discover (both enumerate devices), though the LAN-mDNS vs. known/cloud distinction is spelled out. Minor boundary blurring keeps it just under perfect.

    Naming Consistency4/5

    Uniform shelly_ prefix and snake_case throughout, with domain-grouped names (scene_, schedule_, script_, kvs_, webhook_, virtual_) that are highly predictable. The one deviation is the control group using noun_verb (switch_set, light_set, cover_move) vs. verb_noun elsewhere (list_components, get_status), which is consistent within its group but not across the whole set.

    Tool Count3/5

    47 tools is heavy (well above the ~15 ideal) and will burden selection, but the surface genuinely spans many independent subsystems — devices, KVS, scenes, schedules, scripts, webhooks, virtual components, energy, and system ops — each legitimately needing CRUD. It is large but not a mismatch the way a 50+ grab-bag would be.

    Completeness5/5

    Near-complete lifecycle coverage: CRUD for KVS, schedules, webhooks, scripts, and virtual components; create/run/delete for scenes (with overwrite covering update); device discovery, info, status, config, energy live+history, and system reboot/update/auth. The read/write RPC escape hatches (shelly_rpc, shelly_rpc_write) close any residual gaps, leaving no obvious dead ends.

    Maintenance

    ActivityMaintained
    ResponsivenessNo issues

    Resources