Stophy
Server Details
YouTube data MCP server for AI agents. Search YouTube, fetch transcripts, read comments and replies, inspect channels, analyze playlists, and retrieve video details through Stophy’s hosted API.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.5/5 across 6 of 6 tools scored.
Each tool has a clearly distinct purpose: channel, video, playlist, suggestions, search, and credits. No overlap in functionality.
All tools follow the 'stophy_get_<resource>' pattern except 'stophy_search_videos', which uses 'search' instead of 'get'. The prefix is consistent, and the pattern is predictable.
Six tools cover the essential operations for a YouTube data retrieval API (channel, video, playlist, search, suggestions, credits). The count is well-scoped.
The tool set covers major use cases: channel browsing, video details with transcript/comments, playlist retrieval, search, and suggestions. Only minor gaps like direct channel-by-handle retrieval are missing, but overall it's complete for a read-only API.
Available Tools
6 toolsstophy_get_channelARead-onlyInspect
Browse a YouTube channel's content. Returns channel{id, name, handle, subscriberCount, videoCount, isVerified, thumbnails} on every tab. Video/short/playlist tabs also return items[{id, videoUrl, title, author, publishedAt, thumbnails}] and continuationToken. About tab returns the full profile including country, joinedDate, viewCount, and links[]. Best for: auditing a creator's catalog, pulling all videos from a channel, reading channel description. Not recommended for: fetching a single known video. Use stophy_get_video instead.
| Name | Required | Description | Default |
|---|---|---|---|
| tab | No | Which channel tab to read | video |
| sortBy | No | Sort order for the tab | |
| channelUrl | Yes | Channel URL (e.g. https://youtube.com/@handle) | |
| continuationToken | No | Pagination token from a previous channel response |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and destructiveHint=false, confirming safe read-only operation. The description adds rich behavioral details: per-tab return fields, continuation token, and profile info. No contradictions.
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 well-structured with key info front-loaded. It could be slightly more concise but effectively covers purpose, usage, and behavior without excess.
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?
No output schema exists, but the description sufficiently explains return values for each tab, including fields and continuation token. It covers the main use cases and constraints, making it complete enough for the tool's complexity.
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 coverage is 100% with parameter descriptions. The description adds value by explaining how tab and sortBy affect output and mentioning return structure, beyond schema basics.
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 'Browse a YouTube channel's content' and details the return structure per tab. It distinguishes the tool from siblings by name and use case, making it specific and unambiguous.
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 explicitly lists best use cases (auditing catalog, pulling all videos) and a not-recommended case (fetching single video), directing to sibling tool stophy_get_video. This provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
stophy_get_creditsARead-onlyInspect
Check your remaining Stophy API credit balance. Returns {credits: number}. Does not consume a credit. Use before running large batch jobs to confirm you have enough credits.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide read-only hint; description adds that it does not consume a credit and returns a specific shape, enhancing transparency.
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 concise sentences: first states purpose and return, second gives usage advice. Perfectly front-loaded and no wasted words.
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 zero-parameter tool with no output schema, the description covers purpose, usage context, return shape, and non-destructive nature. Fully 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?
No parameters, so description's role is minimal. It correctly describes the function and return value, adding value beyond 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 action ('Check your remaining Stophy API credit balance') and mentions the return type. It distinguishes from sibling tools which retrieve different resources.
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?
Explicitly advises using before large batch jobs, and notes that it does not consume a credit. Lacks explicit when-not-to-use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
stophy_get_playlistARead-onlyInspect
Get all videos in a YouTube playlist. Returns playlist{id, title, author} and items[{id, videoUrl, title, author, publishedAt, thumbnails}] with continuationToken. Best for: processing curated collections, course playlists, or a channel's uploads playlist.
| Name | Required | Description | Default |
|---|---|---|---|
| playlistUrl | Yes | Playlist URL (e.g. https://youtube.com/playlist?list=PLAYLIST_ID) | |
| continuationToken | No | Pagination token from a previous playlist response |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by detailing the response format and pagination via continuationToken, but does not cover rate limits or authentication requirements.
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 two sentences that efficiently state the tool's function, return structure, and best-use cases without redundancy or unnecessary detail.
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?
Despite lacking an output schema, the description includes the return format and pagination. With full schema coverage for parameters and annotations clarifying read-only behavior, the description covers all necessary context for an agent to use the tool correctly.
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 coverage is 100%, so the schema already fully describes both parameters. The description mentions continuationToken for pagination but adds no new meaning beyond what the schema provides, meeting the baseline expectation.
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 retrieves all videos from a YouTube playlist, specifies the return structure including playlist and items with continuationToken, and provides use cases that differentiate it from sibling tools like stophy_get_channel or stophy_search_videos.
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 gives concrete best-use examples (curated collections, course playlists, channel uploads) and implicitly suggests when to use this over alternatives, but does not explicitly exclude cases or name alternative tools directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
stophy_get_suggestionsARead-onlyInspect
Get YouTube autocomplete suggestions for a partial query. Returns {q, hl, gl, suggestions: string[]}. Best for: query expansion, topic discovery, and building search UIs.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Partial query to autocomplete | |
| gl | No | Region code (ISO 3166-1 alpha-2) | US |
| hl | No | Language code (ISO 639-1) | en |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds marginal value by specifying the return type, but lacks details on rate limits or auth.
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 succinct sentences with front-loaded purpose and return shape. No unnecessary words.
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 simple autocomplete functionality, the description is complete: specifies input (partial query), return shape, and use cases. No output schema 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 input schema covers all three parameters (q, gl, hl) with full descriptions (100% coverage). The description adds no new parameter meaning beyond 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 gets YouTube autocomplete suggestions for a partial query, and the use cases distinguish it from siblings like stophy_search_videos or stophy_get_video.
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 clear usage context ('Best for: query expansion, topic discovery, and building search UIs') but does not explicitly state when not to use it or compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
stophy_get_videoARead-onlyInspect
Fetch details, transcript, comments, comment replies, or live chat for a YouTube video. type="details": returns video{id, title, author, description, viewCount, likeCount, durationSec, publishedAt, tags, isLive} and related[]. type="transcript": returns {videoId, language{code, name, isAutoGenerated}, segments[{text, start, duration}], text}. type="comments": returns {videoId, items[{id, text, author, likeCount, replyCount, repliesToken}], continuationToken}. type="replies": pass the repliesToken of a comment as continuationToken to fetch its replies. type="livechat": returns {videoId, status (live|upcoming|replay|chat_disabled|not_live), isLive, concurrentViewers, messages[{id, text, author, authorId, timestampUsec, isOwner, isModerator, isVerified, superChatAmount}], continuationToken, pollIntervalMs}. Set chatType="top" for moderated Top chat (default) or "live" for all messages. To follow a live stream, poll again passing the previous continuationToken for only new messages, waiting pollIntervalMs between polls; a null continuationToken means the stream ended. Best for: extracting content from a known video URL. Not recommended for: discovering videos. Use stophy_search_videos instead.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | What to fetch: details = title/description/stats, transcript = timestamped captions, comments = threaded comments, replies = replies to a comment, livechat = live stream chat messages + status | |
| sortBy | No | Sort order for comments. Defaults to top | |
| chatType | No | For livechat only: 'top' = Top chat (moderated, default), 'live' = Live chat (all messages). Applied on the first call; later polls keep the chosen mode. | |
| videoUrl | No | YouTube video URL (e.g. https://youtube.com/watch?v=VIDEO_ID). Required for details, transcript, and comments. | |
| continuationToken | No | Pagination token. For comments, pass a previous comments response token. For replies, pass the repliesToken of a comment. For livechat, pass the continuationToken from a previous livechat response to poll for new messages. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive behavior. The description adds rich behavioral context: response structures for each type, polling mechanics with pollIntervalMs, continuationToken semantics (null ends stream), and that chatType is applied only on first call. This goes beyond the annotations.
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 well-structured with clear sections for each type, best use, and pagination. While lengthy, each part serves a purpose and is front-loaded with the core action. Minor redundancy could be trimmed, but overall efficient.
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?
The description is comprehensive given the complexity: multiple types, pagination, live streaming details, and no output schema. It covers all necessary usage scenarios and response structures, making it fully actionable for an AI agent.
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 coverage is 100%, so baseline is 3. The description adds value by clarifying the role of each parameter in context, such as continuationToken usage for comments, replies, and livechat, and defaults for sortBy and chatType.
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 fetches various types of content for a YouTube video, specifying each type and its return structure. It also explicitly distinguishes from sibling tools by noting it is best for extracting content from known URLs and suggesting stophy_search_videos for discovery.
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 explicit guidance on when to use this tool (known video URL) and when not to (discovery), with a direct recommendation to use stophy_search_videos as an alternative. It also details usage patterns for each type, including pagination and live stream polling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
stophy_search_videosARead-onlyInspect
Search YouTube by keyword with optional filters. Returns items[] where each item has: type, id, videoUrl, title, author, description, duration, durationSec, viewCount, publishedAt, publishedAtText, thumbnails, isLive. Also returns continuationToken for the next page. Best for: discovering videos on a topic, finding recent uploads. Not recommended for: fetching a specific video you already have the URL for. Use stophy_get_video instead.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Search query | |
| type | No | Filter by content type | |
| sortBy | No | Sort order. Defaults to relevance | |
| duration | No | short = under 4 min, medium = 4–20 min, long = over 20 min | |
| features | No | Filter by video features | |
| uploadDate | No | Filter by upload date | |
| continuationToken | No | Pagination token from a previous search response |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive behavior. The description adds value by detailing the response structure (items with specific fields) and the existence of a continuationToken for pagination, but does not disclose additional behavioral traits like rate limits or required permissions.
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 compact (three sentences) with a clear structure: main action, return fields, and usage guidance. Every sentence serves a purpose, making it easy to scan.
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 complexity (7 parameters, 1 required) and no output schema, the description adequately covers the return format and pagination. It also provides usage context, making it sufficiently complete for an AI agent to decide whether to use this tool.
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 coverage is 100% with comprehensive parameter descriptions including enums and length constraints. The description adds no further semantic detail beyond the schema, so baseline score of 3 is appropriate.
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 action: 'Search YouTube by keyword with optional filters.' It specifies the return structure (items with fields) and distinguishes from the sibling 'stophy_get_video' by explicitly stating best use cases and when not to use it.
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 explicit guidance: 'Best for: discovering videos on a topic, finding recent uploads. Not recommended for: fetching a specific video you already have the URL for. Use stophy_get_video instead.' This clearly defines when to use and when to avoid, with a direct alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!