Skip to main content
Glama
jogalleciez

StreamElements MCP Server

by jogalleciez
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Update custom command

commands_update
Idempotent

Update a StreamElements custom command by sending every field from a prior get with your edits, since the API may replace it entirely.

Instructions

Update a custom command. The API may treat this as a full replacement, so the safest approach is to send every field from commands_get with your changes applied.

Input Schema

NameRequiredDescriptionDefault
costNoLoyalty points it costs to use
typeNoResponse type; 'say' (the default) posts the reply in chat
regexNoRegular expression that triggers the command
replyNoResponse text; supports StreamElements variables such as ${user} and ${count}
hiddenNoHide it from the public command list
aliasesNoOther names that trigger the command
channelNoStreamElements channel id (24-char hex). Defaults to SE_CHANNEL_ID or the channel that owns the token.
commandNoCommand name without the ! prefix, e.g. 'discord'
enabledNoWhether the command is enabled
cooldownNoCooldowns in seconds
keywordsNoWords that trigger the command anywhere in a message
commandIdYesCommand id (24-character hex id)
accessLevelNoMinimum permission level to use it. StreamElements permission levels: 100 everyone, 250 subscriber, 300 regular, 400 VIP, 500 moderator, 1000 super moderator, 1500 broadcaster
enabledOnlineNoWhether it works while the stream is live
enabledOfflineNoWhether it works while the stream is offline

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

The annotations already declare the safety profile (not read-only, idempotent, non-destructive, open-world), so the bar is lower. The description adds genuinely useful information beyond them: the API may treat the payload as a full replacement, so omitted fields can be lost — a real behavioral hazard an agent must know.

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?

Two tight sentences with no filler. The core action leads, and the replacement hazard, the single most decision-relevant fact, follows immediately.

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

Completeness4/5

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

For a 15-parameter mutation with nested objects and no output schema, the description covers the critical gotcha (full replacement) and points to commands_get for the correct payload shape. It leaves channel/token defaulting and permission requirements to the schema, which is acceptable given full coverage there.

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 description coverage is 100% across all 15 parameters, including nested cooldown fields, so the schema already carries the parameter meaning. The description adds only the meta-advice to reuse every field from commands_get, not any additional per-field semantics.

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?

States a specific verb and resource ('Update a custom command'), which is immediately distinguishable from create/list/delete siblings. It does not, however, differentiate itself from the closely named 'commands_update_default' sibling, which an agent could easily confuse it with.

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 gives an actionable workflow hint by naming commands_get as the source of the full field set, implying a read-before-write pattern. It never states when this tool is preferred over the near-identical 'commands_update_default', and there are no exclusions or prerequisites about permissions or channel scoping.

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

Deploy Server

Other Tools