Skip to main content
Glama

streamdeck_read_plugins

Lists installed Stream Deck plugins and their declared actions—UUIDs, names, states, and inferred settings fields—so you can synthesize a third-party action when no configured instance exists.

Instructions

List installed Stream Deck plugins and their declared actions from the user's Elgato Plugins directory, including each action's UUID, Name, States, and — best-effort — the Settings fields its Property Inspector expects (parsed from the action's PI HTML/JS). Use this to synthesize a NEW third-party action when streamdeck_find_actions finds no configured instance. Prefer find_actions (or read_page.raw) when the user already configured the button/dial in the Stream Deck app — especially for first-party Elgato plugins (OBS, Hue, Spotify, Zoom, …) that ship ELGATO-protected/binary manifests and are reported with parse_status instead of action metadata. settings_fields are heuristic: a missing field is not proof it is unused, and a listed field is not guaranteed required.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "streamdeck_read_plugins"
  }
}

Input Schema

NameRequiredDescriptionDefault
plugin_idNoOptional exact match against manifest UUID, folder stem, folder name, or plugin display name.
include_raw_manifestNoIf true, include raw_manifest for readable JSON manifests. Defaults to false.
include_settings_schemaNoIf true (default), enrich each readable action with state_count and a best-effort settings_fields list inferred from its Property Inspector. Set false to skip PI parsing for a faster, manifest-only listing.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.0

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations supplied, the description carries the full burden and discloses key behavior: manifests come from the user's Plugins directory, first-party/binary manifests are reported via parse_status rather than action metadata, and settings_fields are heuristic. It also clearly qualifies that missing or listed settings fields are not proof of unused or required status.

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?

The description is front-loaded with purpose, then usage, then caveats, and every sentence contributes relevant information. It is dense but appropriately sized for a read/list tool with important caveats about manifest parsing.

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 no annotations and no output schema, the description provides sufficient context: what is read, from where, what is returned, limitations around protected manifests, and how to choose between this tool and its siblings. Nothing critical for correct invocation appears to be missing.

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?

Schema coverage is 100%, so the input schema already documents plugin_id, include_raw_manifest, and include_settings_schema. The description adds useful context about settings_fields being heuristic, but it does not add parameter-specific meaning beyond what the schema provides.

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 states a specific verb and resource: list installed Stream Deck plugins and their declared actions from the Elgato Plugins directory. It distinguishes the tool from sibling find_actions by explaining that this reads plugin manifests rather than configured instances.

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

Usage Guidelines5/5

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

It gives explicit when-to-use guidance: synthesize a NEW third-party action when streamdeck_find_actions finds no configured instance. It also states when not to use it, preferring find_actions or read_page.raw when the user already configured the button or dial, especially for first-party Elgato plugins.

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