Twitch MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct data retrieval purpose: user profile, live status, videos, top streams, top games, channel search, game details, followers, clips, and aggregated insights. No overlap between them.
Naming Consistency4/5
Most tools use the 'get_' prefix pattern, but 'check_user_live' and 'search_channels' deviate from that convention. The underlying verb_noun structure is clear and predictable overall.
Tool Count5/5
10 tools is well-scoped for a Twitch read-only API server, covering discovery, user content, and analytics without unnecessary bloat.
Completeness4/5
The set covers core Twitch data needs: user profiles, live status, videos, clips, followers, top streams/games, search, and insights. Minor gaps exist (e.g., stream schedules) but no critical dead ends for read-only use.
Average 3.7/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only indicates a read operation ('obtiene') and that results reflect current popularity, but it does not mention return format, pagination limits, default sorting, rate limits, or what happens when no parameters are provided. This is a significant gap for an unannotated tool.
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?
The description is a single concise sentence that states the primary function first, then mentions the two optional capabilities. It contains no redundant wording and is easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the core purpose is clear, the description lacks guidance on when to use the tool, what the returned data looks like (since there is no output schema), and behavioral details. For a simple 2-parameter tool, this is minimal but leaves an agent uncertain about expected return values and edge cases.
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%: both 'limit' and 'game_name' have clear descriptions in the schema. The tool description adds only a brief reference to 'filtrar por juego y limitar resultados,' which partly mirrors the schema but does not provide extra meaning beyond it. Baseline of 3 is appropriate.
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 clearly states it retrieves the most popular Twitch streams at the current time, using the verb 'obtiene' and specifying the resource 'streams'. It also distinguishes itself from siblings like get_top_games and get_user_videos by focusing on streams and mentioning optional filtering by game and result limiting.
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 implies usage for getting current popular streams and mentions filter/limit options, but it does not explicitly state when to prefer this tool over alternatives such as search_channels or get_user_videos. No exclusion criteria or alternative tool recommendations are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full transparency burden. It discloses returned fields but omits operational behavior like authentication requirements, rate limits, or error handling for unknown users. 'Obtiene información' suggests a safe read but does not explicitly state non-mutation or other constraints.
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?
The description is a single sentence that front-loads the action and quickly lists relevant returned fields. It is free of filler, and the trailing 'etc.' is an acceptable abbreviation for an open-ended list.
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?
The tool is simple—one required parameter, no output schema—so the description's field list (ID, display name, description, avatar, creation date) meaningfully covers return expectations. However, it does not mention not-found behavior or authentication prerequisites, which would make it fully complete.
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?
The schema already fully describes the 'login' parameter (Twitch username, lowercase), giving 100% schema coverage. The description only paraphrases that it looks up by login, adding no new semantic detail beyond the schema.
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 clearly states it retrieves detailed Twitch user information by login, using the specific verb 'Obtiene' and a defined resource. It distinguishes itself from sibling tools like check_user_live or get_user_videos, which target different data types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives such as check_user_live or get_creator_insights. Usage is only implied by the phrase 'por su nombre de usuario', with no exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It only states the purpose and does not clarify that this is a safe read-only operation, nor does it describe the output format, potential latency from aggregation, or authentication requirements. This is a significant transparency gap.
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?
The description is a single sentence that immediately states the action (generates an executive summary) and lists the included content areas. It is concise with no redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema and annotations, the description should provide more context about the return value and behavior. It mentions the content areas but not the format or how the summary is generated, leaving it partially complete for an aggregation tool.
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?
The schema provides 100% coverage with descriptions for all four parameters, so the baseline is 3. The description does not add parameter-specific meaning beyond the schema, only hinting at the summary components without explaining how parameters affect them.
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 clearly states the tool generates an executive summary for a creator, listing specific content areas (live status, follower growth, recent VODs and clips). This distinguishes it from sibling tools like check_user_live and get_user_clips, which focus on individual data points.
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 implies the tool is for when an aggregated overview is needed, but it does not explicitly say when to use it over siblings or mention exclusions. No alternative tools are referenced, leaving usage guidance implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a read-only operation ('Recupera') and a time-window filter, but no annotations are present to confirm safety or output traits. It does not explain what 'más populares' means, the return format, or edge cases such as no clips found, leaving the agent to infer these details.
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?
The entire description is one focused sentence with no filler, front-loading the verb and resource. It is concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides the core purpose but lacks necessary context for a tool with no output schema and no annotations: response format, sorting rule behind 'más populares', and behavior when no clips exist or the window is empty. It is sufficient for invoking the tool but not fully self-contained.
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?
All three parameters are documented in the schema (100% coverage), so the description does not need to add parameter semantics. The phrase 'ventana de tiempo configurable' mirrors the window_days parameter description but adds no new information about limit or login.
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 clearly states the tool retrieves a channel's most popular clips within a configurable time window, using the specific verb 'Recupera' and a concrete resource ('clips más populares de un canal'). This distinguishes it from siblings like get_user_videos, which concern videos rather than clips.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_user_videos or check_user_live. The description only restates the function without exclusions, prerequisites, or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral disclosure burden. It discloses that it can filter by video type and limit results, which is useful. However, it omits behavior like pagination, error handling, or whether authentication is required, leaving some gaps typical for a read-only tool.
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?
The description is a single, concise sentence in Spanish, front-loaded with the primary action and immediately followed by the key options. Every word earns its place, with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 parameters, no output schema, no annotations), the description adequately explains how to fetch and filter videos. However, it does not specify the return format or pagination behavior, which would be helpful given no output schema is present, leaving moderate completeness.
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?
The input schema has 100% description coverage for all three parameters (login, limit, video_type), so the schema already explains meanings and defaults. The description only echoes the filter and limit capabilities, adding no new semantic detail beyond the schema, making baseline 3 appropriate.
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 clearly states a specific action ('Obtiene los videos de un usuario de Twitch') with a direct verb and resource, and distinguishes it from sibling tools like get_user_clips (clips) and get_twitch_user (user info) by focusing on videos. It also highlights filter and limit options, leaving no ambiguity about its purpose.
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 implies usage context: use this to retrieve a Twitch user's videos, optionally filtered by type and limit. However, it does not explicitly state when not to use it or mention alternatives, relying on the tool name and sibling list for differentiation. No exclusionary guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It only states the search purpose, not details like how live_only filters results, whether limit caps output, or what happens when no matches are found. This lack of behavioral context could lead to incorrect invocation.
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?
The description is two succinct sentences, front-loaded with the primary action and then the use case. Every word is useful, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters and no output schema, and the description is minimal. It clarifies the core search purpose but omits how filters like live_only affect behavior and what the response looks like. The gaps are notable for an agent selecting parameters, though the tool is relatively simple.
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?
The schema provides 100% description coverage for all parameters, so the baseline is 3. The description adds no additional meaning beyond the query term, saying nothing about limit or live_only semantics. It does not compensate beyond what the schema already states.
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 clearly states the tool's function: 'Busca canales de Twitch por nombre o palabras clave' (searches Twitch channels by name or keywords). It also provides a use case ('descubrir nuevos streamers') that differentiates it from exact-lookup siblings like get_twitch_user.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Útil para descubrir nuevos streamers' implies the tool is for exploratory search rather than exact user lookup. It offers clear context but does not explicitly name alternatives or exclusion criteria, such as 'for exact user info, use get_twitch_user instead.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 that the operation is a retrieval ('obtiene') and specifies the output scope (total and recent followers). However, it does not mention authorization requirements or rate limits, but the read-only nature is clear from the verb.
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?
The description is a single, front-loaded sentence that efficiently communicates the tool's purpose without redundant detail. Every word contributes to understanding the tool's core function.
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?
Given the simplicity of the tool and complete schema coverage, the description sufficiently covers the core functionality. It could detail the exact response structure more explicitly since no output schema is provided, but the description's mention of 'total' and 'most recent followers' gives a reasonable picture.
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?
The input schema already provides full descriptions for both 'login' and 'limit', so the description adds little parameter-level detail. It does clarify the output includes a total count and a list of recent followers, but this relates to the response rather than the input parameters.
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 clearly states it retrieves follower statistics for a channel, specifically the total follower count and most recent followers. This distinguishes it from sibling tools like get_twitch_user or check_user_live, which target different aspects of a channel or user.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives such as get_creator_insights. The description only implies its use case by stating what it does, providing no exclusions or context for when another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the return fields (ID, name, box art URL), which is useful, but it doesn't mention any potential errors, rate limits, or confirm that it's a read-only operation beyond the verb 'Obtiene'. The description adds value but lacks deeper behavioral context.
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?
The description is two concise sentences that immediately state what the tool does and what it returns. There is zero filler or redundancy, and the key information is front-loaded.
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 simple single-parameter lookup with no output schema, the description provides sufficient information: it names the resource, the lookup method, and the return fields. It could be slightly more complete by explicitly contrasting with get_top_games, but overall it's adequate for its simplicity.
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?
The schema has 100% coverage for the single parameter game_name, with a clear Spanish description. The tool description adds no additional parameter semantics beyond restating that the game is searched by name. The schema does the heavy lifting, so baseline 3 is appropriate.
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 clearly states a specific verb ('Obtiene'), resource ('información de un juego en Twitch'), and the method ('por su nombre'). It also lists the return fields, distinguishing it from siblings like get_top_games which list games rather than retrieve detail by name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for when you have a specific game name, which distinguishes it from get_top_games or other list-oriented tools. However, it doesn't explicitly state exclusions or name alternative tools, so it's clear but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears responsibility for disclosing behavior. It discloses that the list is sorted by viewer count and current, but does not describe the return format, authentication needs, or rate limits. This is a read-only operation, so risk is low, but additional context would be helpful.
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?
One clear, declarative sentence with no fluff. It front-loads the verb and subject.
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?
The tool is a simple list retrieval with one optional parameter. The description covers the core behavior (what, where, sorting). Since there is no output schema, the return structure is not detailed, but that's not a major gap for such a simple tool.
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?
The schema fully documents the only parameter 'limit' with default, min, max, and a Spanish description. The tool description adds no extra parameter detail beyond the schema, but the baseline for high schema coverage is 3.
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 clearly states the tool retrieves the most popular Twitch games sorted by viewer count, using specific verb 'Obtiene' and resource 'juegos más populares en Twitch'. It distinguishes from sibling tools like get_top_streams (streams vs games) and get_game_info (list vs specific).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving a ranked list of the most popular games currently on Twitch. It does not explicitly name alternative tools or exclusion criteria, but the scope is clear enough to separate it from top streams and game-specific info.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 key behavioral trait: returns stream information if live and null if offline, which is beyond what the schema reveals. It doesn't mention rate limits or error handling, but for a simple status check the core behavior is well covered.
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?
The description is two sentences, front-loaded with the verb and resource, with no wasted words. Every sentence contributes meaningful information.
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?
The description explains the return behavior (stream information or null), which is necessary because no output schema exists. The single parameter is well-defined. It is complete for a simple status check, though it leaves the exact contents of 'stream information' unspecified.
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% (the 'login' parameter is described as 'Nombre de usuario de Twitch (login name)'). The tool description adds no additional parameter semantics, so it aligns with the baseline of 3 for high schema coverage.
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 uses a specific verb ('Verifica') and clearly identifies the resource (un usuario de Twitch) and the condition being checked (si está transmitiendo en vivo). It distinguishes this tool from sibling tools like get_twitch_user (profile) or get_top_streams (global list) by focusing on a single user's live status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context on when to use the tool: to check if a specific Twitch user is currently live, returning null if offline. However, it does not explicitly name alternatives or state when not to use this tool, so it stops short of the highest tier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![twitch_mcp MCP server](https://glama.ai/mcp/servers/hizokabenitez/twitch_mcp/badges/card.svg)](https://glama.ai/mcp/servers/hizokabenitez/twitch_mcp)

Score Badge

Copy to your README.md:

[![twitch_mcp MCP server](https://glama.ai/mcp/servers/hizokabenitez/twitch_mcp/badges/score.svg)](https://glama.ai/mcp/servers/hizokabenitez/twitch_mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/hizokabenitez/twitch_mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server