Skip to main content
Glama
Buggy1111

shelly-mcp

by Buggy1111

shelly_scene_run

Runs a named Shelly scene sequentially, attempts every action, reports per-action results, and continues after failures so partial runs can be safely re-run.

Instructions

Run a named scene: attempt every action in order, report per-action results.

Best-effort and sequential — a failing action does not abort the rest. status is ok (all succeeded), partial (some failed), or failed (none succeeded). A partial run can simply be re-run later to finish it (scenes use absolute states, so re-running is safe). Every action is audit-logged.

Input Schema

NameRequiredDescriptionDefault
nameYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.1.3
    • addedInput schema / additionalProperties
      Added value: +false
  2. First observedv0.1.2

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so well: it discloses sequential best-effort execution, that a failing action does not abort the rest, the exact status vocabulary (ok/partial/failed), idempotency because scenes use absolute states, and that every action is audit-logged. This is the behavioral context an agent needs before invoking a mutating tool.

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?

Front-loaded with the core action in line one, then structured into behavioral detail. Every sentence carries information; the only mild redundancy is restating 'best-effort and sequential' after the first line already implied it.

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?

An output schema exists so return-value documentation is not strictly required, yet the description still defines the status field semantics, and it covers failure handling and re-run safety. Nothing needed to invoke this one-parameter tool correctly is missing.

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?

Schema coverage is 0% and the single 'name' parameter has no schema description, so the description must carry the meaning. 'Run a named scene' makes clear the parameter identifies a scene, which is adequate compensation although no naming/format convention is given.

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?

Specific verb+resource: 'Run a named scene', immediately setting it apart from shelly_scene_list, shelly_scene_get, shelly_scene_create and shelly_scene_delete. The first line alone tells an agent exactly what the tool does.

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?

Explains the execution model (best-effort, sequential) and gives concrete operational guidance: a partial run can simply be re-run later. It does not explicitly contrast with direct-control siblings like shelly_switch_set or shelly_light_set, so the alternative-selection guidance is implicit rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.