Enables management of Facebook as a streaming destination through Restream, including listing connected channels, enabling/disabling streaming, and controlling stream settings.
Enables management of Twitch as a streaming destination through Restream, including listing connected channels, enabling/disabling streaming, and controlling stream settings.
Enables management of YouTube as a streaming destination through Restream, including listing connected channels, enabling/disabling streaming, and controlling stream settings.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Restream MCP Server list all my connected streaming channels"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that provides tools for interacting with the Restream API. This server enables Claude and other MCP clients to manage streaming channels, control streams, and access analytics through natural language.
User Profile Management: Get authenticated user information
Channel Management: List, view, enable/disable streaming channels
Stream Control: Start, stop, and update stream settings
Analytics: Access streaming analytics and performance data
OAuth Authentication: Secure API access using client credentials
Related MCP server: codivupload-mcp
get_user_profileGet the authenticated user profile information including email, display name, and account details.
list_channelsList all connected streaming channels/platforms (YouTube, Twitch, Facebook, etc.) with their connection status.
get_channelGet detailed information about a specific channel by ID.
Parameters:
channelId (string, required): The ID of the channel to retrieve
update_channel_statusEnable or disable a specific streaming channel.
Parameters:
channelId (string, required): The ID of the channel to update
enabled (boolean, required): Whether to enable (true) or disable (false) the channel
get_current_streamGet information about the current/active stream including title, status, RTMP URL, and viewer count.
update_stream_settingsUpdate settings for the current stream such as title, description, or privacy settings.
Parameters:
title (string, optional): The stream title
description (string, optional): The stream description
privacy (string, optional): The stream privacy setting (public, private, unlisted)
get_stream_analyticsGet analytics and statistics for streams including viewer counts, engagement metrics, and performance data.
Parameters:
streamId (string, optional): Optional stream ID to get analytics for a specific stream
start_streamStart a new stream with optional settings.
Parameters:
title (string, optional): The stream title
description (string, optional): The stream description
privacy (string, optional): The stream privacy setting (public, private, unlisted)
stop_streamStop the current active stream.
Node.js 18 or higher
npm or yarn
Restream API credentials (Client ID and Client Secret)
npm install -g @shaktech786/restream-mcp-serverOr install locally in your project:
npm install @shaktech786/restream-mcp-serverClone this repository:
git clone https://github.com/shaktech786/restream-mcp-server.git
cd restream-mcp-serverInstall dependencies:
npm installBuild the server:
npm run buildConfigure your Restream API credentials either through environment variables or in your Claude Desktop config:
Environment Variables (.env file):
RESTREAM_CLIENT_ID=your_client_id_here
RESTREAM_CLIENT_SECRET=your_client_secret_here
RESTREAM_API_BASE_URL=https://api.restream.io/v2Create a new application or use an existing one
Copy your Client ID and Client Secret
Add them to your .env file
To use this MCP server with Claude Desktop, add it to your Claude Desktop configuration file:
Windows: %APPDATA%\Claude\claude_desktop_config.json
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
{
"mcpServers": {
"restream": {
"command": "npx",
"args": ["-y", "@shaktech786/restream-mcp-server"],
"env": {
"RESTREAM_CLIENT_ID": "your_client_id_here",
"RESTREAM_CLIENT_SECRET": "your_client_secret_here",
"RESTREAM_API_BASE_URL": "https://api.restream.io/v2"
}
}
}
}{
"mcpServers": {
"restream": {
"command": "node",
"args": ["/absolute/path/to/restream-mcp-server/dist/index.js"],
"env": {
"RESTREAM_CLIENT_ID": "your_client_id_here",
"RESTREAM_CLIENT_SECRET": "your_client_secret_here",
"RESTREAM_API_BASE_URL": "https://api.restream.io/v2"
}
}
}
}Restart Claude Desktop after saving the configuration.
npm run devThis will watch for changes and rebuild automatically.
You can test the server locally using the MCP Inspector:
npx @modelcontextprotocol/inspector node dist/index.jsThis server uses the Restream API v2. The main endpoints include:
POST /oauth/token - Authentication
GET /user/profile - Get user profile
GET /user/channels - List channels
GET /user/channels/:id - Get channel details
PATCH /user/channels/:id - Update channel
GET /user/stream - Get current stream
PATCH /user/stream - Update stream settings
POST /user/stream/start - Start stream
POST /user/stream/stop - Stop stream
GET /user/analytics - Get analytics
For complete API documentation, visit Restream Developer Portal.
Once configured, you can ask Claude to:
"List all my connected streaming channels"
"Get my current stream information"
"Update my stream title to 'Live Coding Session'"
"Enable my YouTube channel"
"Show me my streaming analytics"
"Start a new stream with title 'Gaming Night'"
If you encounter authentication errors:
Verify your Client ID and Client Secret are correct
Ensure the credentials have the necessary permissions
Check that the API base URL is correct
If the server fails to connect:
Make sure all dependencies are installed (npm install)
Rebuild the server (npm run build)
Check that Node.js version is 18 or higher
Verify the path in Claude Desktop config is correct
Never commit your .env file to version control
Keep your Client ID and Client Secret secure
Regularly rotate your API credentials
The .gitignore file is configured to exclude .env
MIT
Contributions are welcome! Please feel free to submit issues or pull requests.
For issues with the MCP server, please file an issue on GitHub.
For Restream API questions, visit the Restream Developer Portal.
Get detailed information about a specific channel by ID
| Name | Required | Description | Default |
|---|---|---|---|
| channelId | Yes | The ID of the channel to retrieve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a read operation ('Get'), but doesn't mention permissions required, rate limits, error conditions, or what 'detailed information' includes. This leaves significant gaps for a tool that presumably returns channel metadata.
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?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's appropriately sized for a simple retrieval tool and front-loads the core purpose immediately.
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 retrieval tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'detailed information' includes, potential response formats, or error handling. Given the context of sibling tools for streams and channels, more completeness about channel-specific data would be helpful.
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?
The schema description coverage is 100%, with the single parameter 'channelId' fully documented in the schema. The description adds no additional parameter context beyond implying retrieval by ID, so it meets the baseline for high schema coverage without compensating value.
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 clearly states the action ('Get detailed information') and target resource ('about a specific channel by ID'), which is a specific verb+resource combination. However, it doesn't differentiate this tool from its sibling 'list_channels' or other channel-related tools, so it doesn't fully distinguish from alternatives.
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?
The description provides no guidance on when to use this tool versus alternatives like 'list_channels' for browsing channels or 'get_current_stream' for stream-specific data. There's no mention of prerequisites, appropriate contexts, or exclusions, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about the current/active stream including title, status, RTMP URL, and viewer count
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly indicates this is a read operation ('Get information'), which is helpful. However, it doesn't mention potential behavioral aspects like authentication requirements, rate limits, error conditions, or whether the data is real-time vs cached. The description adds basic context but lacks comprehensive behavioral details.
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?
The description is a single, efficient sentence that front-loads the core purpose ('Get information about the current/active stream') followed by specific attributes. There's zero wasted language, and every word contributes to understanding what the tool does.
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?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is reasonably complete for a basic read operation. It specifies what information will be retrieved. However, for a tool without annotations or output schema, it could benefit from mentioning the return format or data structure since the agent won't know what to expect from the response.
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?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the parameter situation. The description appropriately doesn't discuss parameters since none exist. It earns a baseline 4 because when there are no parameters, the description doesn't need to compensate for schema gaps.
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 clearly states the tool's purpose: 'Get information about the current/active stream' with specific attributes listed (title, status, RTMP URL, viewer count). It uses a specific verb ('Get') and identifies the resource ('current/active stream'), but doesn't explicitly differentiate from sibling tools like 'get_stream_analytics' or 'get_channel'.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when this tool is appropriate compared to siblings like 'get_stream_analytics' (which might provide more detailed metrics) or 'get_channel' (which might provide broader channel information). No exclusions or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get analytics and statistics for streams including viewer counts, engagement metrics, and performance data
| Name | Required | Description | Default |
|---|---|---|---|
| streamId | No | Optional stream ID to get analytics for a specific stream. If not provided, returns analytics for the current user |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states what data is returned but lacks critical details: it doesn't specify whether this requires authentication, mention rate limits, describe the format or structure of returned data, or indicate if it's a read-only operation (though implied by 'Get'). This leaves significant gaps for a tool that presumably accesses sensitive analytics.
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?
The description is a single, efficient sentence that front-loads the core purpose and lists key data types without redundancy. Every word contributes meaning, and there's no wasted verbiage, making it easy for an agent to parse quickly.
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?
Given the complexity of analytics tools (which often involve permissions, data formats, and scope), the description is incomplete. With no annotations and no output schema, it fails to address authentication needs, return structure, or error handling. This leaves the agent under-informed for safe and effective use.
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%, so the schema already fully documents the single optional parameter 'streamId'. The description adds no additional parameter semantics beyond what's in the schema, such as clarifying what 'current user' means or providing examples of stream IDs. The baseline score of 3 reflects adequate but minimal value added.
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 clearly states the tool's purpose with specific verbs ('Get analytics and statistics') and resources ('streams'), and identifies the types of data returned ('viewer counts, engagement metrics, and performance data'). However, it doesn't explicitly differentiate this tool from potential sibling analytics tools, though none are listed among the siblings.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, timing considerations, or how it relates to sibling tools like 'get_current_stream' or 'list_channels', leaving the agent to infer usage context independently.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the authenticated user profile information including email, display name, and account details
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states this retrieves 'authenticated user' information, implying it requires authentication, which is useful behavioral context. However, it doesn't disclose other traits like rate limits, error conditions, or whether this is a read-only operation (though implied by 'Get'). For a tool with zero annotation coverage, this leaves significant gaps in behavioral understanding.
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?
The description is a single, efficient sentence that front-loads the core purpose and includes specific examples of returned data. Every word earns its place with no redundancy or unnecessary elaboration.
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?
Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is adequate but has clear gaps. It specifies what data is returned, which helps, but lacks information on authentication requirements, error handling, or return format. For a simple read operation, this is minimally viable but could be more complete.
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?
The input schema has 0 parameters with 100% coverage, so the schema fully documents the lack of inputs. The description adds no parameter information, which is appropriate here. Baseline is 4 for 0 parameters, as there's nothing to compensate for, and the description doesn't contradict the schema.
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 clearly states the tool's purpose with a specific verb ('Get') and resource ('authenticated user profile information'), listing specific data fields returned (email, display name, account details). It doesn't distinguish from sibling tools, but none of the siblings appear to retrieve user profiles, making differentiation less critical.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication requirements), nor does it clarify if this is for the current user versus looking up other users. With siblings focused on channels and streams, there's no explicit comparison or exclusion criteria provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all connected streaming channels/platforms (YouTube, Twitch, Facebook, etc.) with their connection status
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the tool lists channels with connection status, which is useful behavioral context. However, it doesn't mention potential limitations (e.g., rate limits, authentication needs, or what 'connected' means), leaving gaps in transparency for a tool with no annotation support.
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?
The description is a single, efficient sentence that front-loads the core purpose ('List all connected streaming channels/platforms') and adds clarifying details ('with their connection status'). Every word earns its place with no redundancy or waste.
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?
Given the tool's simplicity (0 parameters, no annotations, no output schema), the description is reasonably complete for a list operation. It specifies what is listed and includes connection status, but lacks details on output format (e.g., structure of returned data) which could be helpful since there's no output schema.
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?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description adds no parameter-specific information, but with no parameters, the baseline is 4 as it doesn't need to compensate for schema gaps.
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 clearly states the verb 'List' and the resource 'all connected streaming channels/platforms' with specific examples (YouTube, Twitch, Facebook). It distinguishes from siblings by focusing on listing all channels rather than getting a specific channel (get_channel) or managing streams (start_stream, stop_stream).
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?
The description implies usage context by specifying 'all connected streaming channels/platforms' and 'connection status,' which suggests this tool is for inventory/status checks. However, it doesn't explicitly state when to use this versus alternatives like get_channel (for a single channel) or update_channel_status (for modifying status).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a new stream with optional settings
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | The stream title | |
| description | No | The stream description | |
| privacy | No | The stream privacy setting |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is a 'Start' action, implying a creation/mutation operation, but doesn't disclose any behavioral traits such as permissions required, whether this is idempotent, what happens if a stream is already running, or any rate limits. The description adds minimal context beyond the basic action.
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?
The description is a single, efficient sentence that is front-loaded with the core action ('Start a new stream') and adds a brief qualifier ('with optional settings'). There is no wasted language, and every word earns its place in conveying the essential information.
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?
Given this is a mutation tool (starting a stream) with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns, potential side effects, error conditions, or how it interacts with sibling tools. For a tool that likely creates a resource, more context is needed to guide effective use.
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%, so the schema already documents all three parameters (title, description, privacy) with descriptions and an enum for privacy. The description adds no additional meaning beyond implying these are 'optional settings', which aligns with the schema but doesn't provide extra semantic context. Baseline 3 is appropriate when schema does the heavy lifting.
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 states the action ('Start a new stream') which is a clear verb+resource combination, but it's vague about what 'stream' means in this context and doesn't distinguish this from sibling tools like 'get_current_stream' or 'stop_stream'. The 'optional settings' part adds some specificity but remains general.
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?
The description provides no guidance on when to use this tool versus alternatives like 'update_stream_settings' or 'stop_stream'. It mentions 'optional settings' but doesn't clarify what scenarios require starting a new stream versus modifying an existing one or what prerequisites might be needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop the current active stream
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the action without behavioral details. It doesn't disclose whether stopping is reversible, requires specific permissions, affects related resources, or has side effects like analytics termination. For a mutation tool with zero annotation coverage, this is inadequate.
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?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it immediately understandable without redundancy.
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 mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'stop' entails behaviorally, what happens to the stream post-stop, or what (if anything) is returned. Given the complexity of stopping an active process, more context is needed.
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?
The tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, earning a baseline 4 for not adding unnecessary information.
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 'Stop the current active stream' clearly states the action (stop) and target resource (current active stream). It distinguishes from siblings like 'start_stream' (opposite action) and 'get_current_stream' (read-only). However, it doesn't specify what constitutes 'active' or differentiate from other stream management tools like 'update_stream_settings'.
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?
The description implies usage when there's an active stream to stop, but provides no explicit guidance on when to use this versus alternatives like 'update_stream_settings' for modifying rather than stopping. No prerequisites, error conditions, or sibling tool comparisons are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enable or disable a specific streaming channel
| Name | Required | Description | Default |
|---|---|---|---|
| channelId | Yes | The ID of the channel to update | |
| enabled | Yes | Whether to enable (true) or disable (false) the channel |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. While 'Enable or disable' implies a mutation operation, the description doesn't address permissions needed, whether changes are reversible, rate limits, side effects on active streams, or what happens after the operation completes. This leaves significant behavioral gaps for a mutation tool.
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?
The description is a single, efficient sentence that communicates the core purpose without unnecessary words. It's appropriately sized for a simple tool with two parameters and gets straight to the point.
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 mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'enabled' or 'disabled' mean functionally, what the response looks like, error conditions, or how this operation interacts with sibling tools like 'start_stream' and 'stop_stream'. The description leaves too many contextual questions unanswered.
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%, with both parameters clearly documented in the schema. The description adds no additional parameter semantics beyond what's already in the schema (channel ID and enable/disable boolean). The baseline score of 3 reflects adequate but minimal value added by the description.
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 clearly states the action ('Enable or disable') and resource ('a specific streaming channel'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'update_stream_settings' or explain how channel status differs from stream control operations.
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?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'start_stream', 'stop_stream', and 'update_stream_settings', there's no indication whether channel status is a separate administrative control, a prerequisite for streaming, or how it relates to other channel operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update settings for the current stream such as title, description, or privacy settings
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | The stream title | |
| description | No | The stream description | |
| privacy | No | The stream privacy setting |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is an update operation (implying mutation) but doesn't cover permissions needed, whether changes are reversible, rate limits, error conditions, or what happens to unspecified settings. For a mutation tool with zero annotation coverage, this leaves significant gaps.
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?
The description is a single, efficient sentence that front-loads the core action and key parameters. Every word earns its place with no redundancy or fluff, making it easy to parse quickly.
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?
Given this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns, error handling, or behavioral nuances. While schema coverage is high for inputs, the overall context for safe and effective use is lacking.
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%, so parameters are fully documented in the schema. The description adds minimal value by listing the same three parameters (title, description, privacy) without providing additional context like format constraints or interdependencies. Baseline 3 is appropriate when schema does the heavy lifting.
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 clearly states the verb 'Update' and resource 'settings for the current stream', specifying what fields can be modified (title, description, privacy settings). It distinguishes from siblings like 'update_channel_status' by focusing on stream settings rather than channel status. However, it doesn't explicitly contrast with all siblings like 'start_stream' or 'stop_stream'.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an active stream), exclusions, or comparisons with sibling tools like 'update_channel_status'. The agent must infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose with no ambiguity. For example, get_channel retrieves channel details, while update_channel_status enables/disables channels, and start_stream/stop_stream manage stream lifecycle. The descriptions clearly differentiate between channel operations, stream operations, analytics, and user profile.
All tools follow a consistent verb_noun pattern with snake_case throughout. Verbs like get, list, start, stop, and update are used predictably, making the tool set easy to navigate. There are no deviations in naming conventions.
With 9 tools, the server is well-scoped for managing streaming operations. Each tool earns its place by covering distinct aspects like channel management, stream control, analytics, and user info, without being overwhelming or insufficient for the domain.
The tool set provides complete CRUD/lifecycle coverage for streaming management. It includes operations for listing and getting channels, starting/stopping streams, updating settings and statuses, retrieving analytics, and accessing user profiles, with no obvious gaps that would hinder agent workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Multistream to Twitch, YouTube and Kick; generate OBS overlays from a plain-English prompt.
Query your Twitch streams, events, supporters, raids & rankings from an AI assistant via OAuth.
Manage videos, playlists, analytics, and monetization for OTT streaming services.
Manage videos and live streams, inspect captions, players and webhooks, and read play analytics.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/shaktech786/restream-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
