Skip to main content
Glama

StreamElements MCP Server and API by Cotlet

Adjust loyalty points in StreamElements

streamelements_adjust_loyalty_points
Read-onlyIdempotent

Adjust loyalty points in the user's own StreamElements account from ChatGPT, Claude or any AI agent. Returns how to do it in StreamElements step by step (screens, buttons, fields) and opens nothing by itself; then do it with the cotlet_browser_* tools in the user's StreamElements Cloud Browser. StreamElements's official API: StreamElements has a full REST API (kappa v2) with a documented OAuth2 flow, but no official MCP server (checked 17 Oct 2026).

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": "streamelements_adjust_loyalty_points"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, and the description is consistent with them by stating it opens nothing by itself. Beyond that it adds useful context: the return content is procedural instructions, and the API/MCP note explains why browser automation is the execution path rather than a REST call.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The workflow-relevant information is front-loaded, but the opening marketing-style phrasing ('from ChatGPT, Claude or any AI agent') and the trailing API/OAuth2 history ('checked 17 Oct 2026') add length without helping the agent decide or invoke. The core signal could be delivered in one tighter sentence.

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?

With no parameters, no output schema, and rich annotations, the description supplies what is missing: what it returns and which tools carry out the action. Only the relationship to the sibling guide tool is left unexplained, which is a minor gap for a simple zero-arg tool.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. No misleading parameter hints are given.

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?

The description states the concrete outcome: it returns step-by-step instructions (screens, buttons, fields) for adjusting loyalty points, and explicitly says it 'opens nothing by itself.' The opening sentence ('Adjust loyalty points... from ChatGPT, Claude or any AI agent') reads initially like the tool performs the action, but the second sentence corrects this. An agent can tell it is a guidance tool rather than a mutation tool, though the framing creates momentary ambiguity.

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?

It gives a clear follow-up path: use this first, then execute via the cotlet_browser_* tools in the StreamElements Cloud Browser. However, it never says when NOT to use it or how it relates to the sibling cotlet_app_guide tool, so the agent must infer which guidance tool to pick.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.