Explains how to sign in and navigate StreamElements screens to list and edit chat commands, so call it first before managing commands.
How to work in StreamElements (list and edit chat commands): its screens and the sign-in link. Call this first.
| Name | Required | Description | Default |
|---|---|---|---|
| task | No | What you want done in StreamElements, in your words. |
Changes observed during successful MCP inspections.
v1.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full burden. It hints that a sign-in link may be returned, but it never says whether the tool only returns instructions or takes any action, nor what format the guidance arrives in. For a low-risk guide tool this is acceptable but thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the subject front-loaded and the sequencing rule at the end. The parenthetical and the odd colon usage add a little friction but nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter guide tool with no output schema, the agent still lacks a sense of what comes back (steps, screens list, sign-in URL) and how to combine that with the sibling open/click/type tools. It is adequate but leaves a meaningful gap about the workflow it is meant to unlock.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single optional 'task' parameter, and the description adds no further meaning about how to phrase it or what happens when it is omitted. Baseline 3 applies since the schema already does the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource (StreamElements: screens, sign-in link) and a specific function (guidance on how to list and edit chat commands), which separates it from siblings like streamelements_read or streamelements_click. It is slightly muddled by 'list and edit chat commands', which could be read as the tool performing those actions rather than explaining them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Call this first.' gives an explicit ordering rule that routes the agent here before the other streamelements_* tools. It does not state when to skip it (for example, after orientation is already done), which keeps it short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.