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.
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.
Average 4.5/5 across 8 of 8 tools scored. Lowest: 3.6/5.
Each tool targets a distinct YouTube data domain: channel browsing, playlist fetching, video details, search, suggestions, kids, music, and credits. Descriptions clearly differentiate them, with no functional overlap.
Most tools follow a consistent 'stophy_get_<noun>' pattern (get_channel, get_credits, etc.), but 'stophy_kids' and 'stophy_music' break the pattern by using a noun-only name with type parameters, introducing minor inconsistency.
With 8 tools, the server is well-scoped for a YouTube data extraction service. Each tool covers a distinct aspect of YouTube (channels, playlists, videos, search, kids, music, suggestions, credits), without unnecessary bloat.
The tool set provides comprehensive coverage for read-only YouTube operations: channel details, playlist tracks, video metadata with transcript/comments/live chat, search, suggestions, kids-safe content, and music-specific features. No obvious gaps for the intended use case.
stophy_get_channelABrowse a YouTube channel's content. Returns channel{id, name, handle, subscriberCount, videoCount, isVerified, thumbnails} on every tab. tab options: video, short, live (past live streams), playlist, post (community posts), about. Video and live tabs return items[{id, videoUrl, title, author, publishedAt, thumbnails}]; the short tab returns items with shortUrl instead of videoUrl (no publishedAt); the playlist tab returns items[{id, playlistUrl, title, videoCount, thumbnails}]. All of these paginate with continuationToken. The post tab returns items[{id, url, content, publishedTimeText, likeCountText, commentCountText, images, video}]. About tab returns the full profile including country, joinedDate, viewCount, and links[]. Set query to search within the channel (returns matching videos; tab is ignored). Best for: auditing a creator's catalog, pulling all videos from a channel, finding a channel's video on a topic, reading community posts or the 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, short, live (past live streams), playlist, community (posts), course, or about | video |
| query | No | Search within this channel. When set, returns the channel's videos matching the query and the tab is ignored | |
| 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true; description adds detailed per-tab return structures, pagination via continuationToken, and query behavior (tab ignored). 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?
Description is long but logically organized: purpose, tab structures, pagination, search behavior, best/not-recommended. Some redundancy but all sentences add value.
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 high complexity (multiple tabs, different return formats, pagination, query) and no output schema, the description fully covers expected behavior and structures, ensuring adequate context for correct invocation.
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, but the main description adds significant context: exact return fields per tab, pagination details, and query behavior. This goes beyond schema, justifying a score above baseline 3.
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 lists specific return fields. It distinguishes from sibling tools by explicitly recommending stophy_get_video for single 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?
Explicit best-for scenarios (auditing a creator's catalog, reading posts) and not-recommended cases (single video) with clear alternative. Also explains when query overrides tab.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
stophy_get_creditsACheck 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 | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds 'Does not consume a credit,' which is valuable behavioral context beyond 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?
Two short, front-loaded sentences with zero wasted words. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only balance check with no parameters and no output schema, the description fully covers purpose, behavior, return type, and usage context.
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 exist, and schema coverage is 100%. Baseline of 4 is appropriate since description correctly omits parameter details.
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 uses a specific verb ('Check') and resource ('your remaining Stophy API credit balance'), clearly distinguishing it from sibling tools like stophy_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?
Explicitly advises use before large batch jobs to verify credit sufficiency, providing clear context. Does not specify when not to use but implies the tool's narrow scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
stophy_get_playlistAGet all videos in a YouTube playlist. Returns playlist{id, playlistUrl, title, author, description, videoCount} 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so description's safety contribution is minimal. It adds pagination behavior (continuationToken) and return structure, but doesn't disclose any behavioral traits beyond what's typical for a read-only list endpoint.
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 efficient sentences: first states purpose and return shape, second lists best-use scenarios. No redundant words or 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?
Description fully covers return structure with field names, mentions pagination, and relates to use cases. Without an output schema, this provides sufficient context for a simple read tool, though it could note any limits on playlist size.
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% (both playlistUrl and continuationToken have descriptions). The description adds no extra semantic meaning 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?
Description clearly states 'Get all videos in a YouTube playlist' and enumerates the returned fields. While it mentions best use cases, it does not explicitly distinguish this tool from siblings like 'stophy_search_videos' which also retrieves 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?
Description provides 'Best for:' guidance (processing curated collections, course playlists, channel uploads) but lacks explicit when-not-to-use or direct comparison with sibling tools. Usage context is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
stophy_get_suggestionsAGet YouTube search autocomplete suggestions for a query. Returns {suggestions: string[]}. Optionally set hl (language, e.g. en) and gl (country, e.g. US). Best for: expanding a seed query into related search phrases, gathering keyword ideas, or seeing what people search for around a term before calling stophy_search_videos.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Search query | |
| gl | No | Country code, e.g. US, GB, DE. Defaults to US | |
| hl | No | Language code, e.g. en, fr, de. Defaults to en |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and destructiveHint=false. The description adds return format ({suggestions: string[]}) and optional parameters, fully disclosing behavior without 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?
Two short sentences plus a 'Best for' clause, all front-loaded with purpose. No fluff or redundant 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?
Tool has 3 simple parameters and is read-only. Description explains return type, optional parameters, and usage scenario, fully covering what an agent needs to invoke it 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?
Input schema covers all parameters with descriptions (100% coverage). Description merely reiterates that hl and gl are optional and gives examples, adding minimal value 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 states it gets YouTube search autocomplete suggestions for a query, specifies the return type, and distinguishes itself from sibling tool stophy_search_videos by noting it's best for expanding seed queries before searching.
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 says 'Best for: expanding a seed query into related search phrases, gathering keyword ideas, or seeing what people search for around a term before calling stophy_search_videos,' providing clear context and an alternative tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
stophy_get_videoAFetch 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}, isTranslated, availableTracks, segments[{text, start, duration}], text}; if the requested lang has no native track, a machine translation is returned along with a top-level warning. type="comments": returns {videoId, sortBy, 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, superChatCurrency}], 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 |
|---|---|---|---|
| lang | No | For transcript only: BCP-47 language code (e.g. en, es, fr, pt-BR). Returns that caption track if it exists, otherwise a machine translation of the default track into that language. Omit for the video's original/auto captions. | |
| 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: any (YouTube's default ordering), top, or latest. Defaults to any | |
| 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, comments, and livechat. | |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors like machine translation fallback for transcripts, live chat status, and polling termination. Annotations indicate read-only, which is consistent with description.
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?
Well-structured with clear sections for each type and usage guidance. Slightly lengthy but every sentence adds value; front-loaded with purpose.
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 no output schema, description provides thorough detail on return structures for all five types, covers edge cases, and explains polling/pagination. Complete for a complex 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%, baseline 3. Description adds value by explaining parameter interactions (e.g., continuationToken usage for replies and livechat), defaults (chatType, sortBy), and requirements (videoUrl for most types).
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 details, transcript, comments, replies, or live chat for a YouTube video, and explicitly distinguishes from sibling tools by recommending stophy_search_videos for video 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?
Provides explicit guidance on when to use (extracting content from known URL) and when not (discovering videos), including alternative tools. Also details polling behavior for live chat and how to fetch replies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
stophy_kidsAtype="search": search YouTube Kids with q and optional continuationToken, returns Kids-safe video items and continuationToken. type="video": fetch YouTube Kids video metadata and related Kids videos from videoUrl. Best for: child-safe discovery and metadata from the YouTube Kids surface.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | YouTube Kids search query | |
| type | Yes | Kids resource to fetch | |
| videoUrl | No | YouTube Kids / YouTube video URL or bare video ID | |
| continuationToken | No | Pagination token from a previous response |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds significant behavioral context by detailing the two modes and their return values (Kids-safe video items, continuationToken for search; video metadata, related Kids videos for video), which goes beyond 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 three sentences, front-loaded with mode definitions. Every sentence provides essential information without redundancy or fluff.
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 explicitly mentions return values for both modes. With 4 parameters fully described in the schema and two modes clearly outlined, the description is sufficiently complete for correct tool selection and invocation.
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%, baseline 3. The description adds meaning by explaining which parameters apply to each type (e.g., q and continuationToken for search; videoUrl for video), enhancing understanding of parameter relationships beyond the schema's individual descriptions.
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 defines two distinct modes (search and video) with specific verbs and resources, and explicitly states 'Best for: child-safe discovery and metadata from the YouTube Kids surface,' distinguishing it from sibling tools like stophy_search_videos and 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 states it is best for child-safe discovery and metadata from the YouTube Kids surface, implying when to use it. It does not explicitly list when not to use or provide alternatives, but the context of sibling tools makes the differentiation clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
stophy_musicAtype="search": search YouTube Music with q and optional searchType (song|video|album|artist|playlist|podcast|episode|profile), returns items[] and continuationToken. type="suggest": autocomplete music queries with q. type="song": fetch rich song metadata from videoUrl. type="lyrics": fetch lyrics from videoUrl. type="album": fetch album metadata and tracks from albumUrl. type="artist": fetch artist profile sections from artistUrl. type="playlist": fetch playlist tracks from playlistUrl and optional continuationToken.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Search or suggestion query | |
| type | Yes | Music resource to fetch | |
| albumUrl | No | YouTube Music album URL or bare MPRE/OLAK album ID | |
| videoUrl | No | YouTube / YouTube Music video URL or bare video ID | |
| artistUrl | No | YouTube Music artist URL or bare UC/MPAD artist ID | |
| searchType | No | Music search result type. Defaults to song | song |
| playlistUrl | No | YouTube / YouTube Music playlist URL or bare playlist ID | |
| continuationToken | No | Pagination token from a previous response |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that operations are read-only (consistent with readOnlyHint=true and destructiveHint=false). It details what each type returns (e.g., search returns items[] and continuationToken, song returns rich metadata). No contradictions with annotations. Could mention that it does not modify data.
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 concise, packing all 7 modes into a single sentence without redundancy. It front-loads the type system and clearly separates each mode with semicolons. It omits fluff, but could break into a list for better readability.
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 (8 params, 7 modes, no output schema), the description covers what each mode returns and required parameters. It does not address error handling or rate limits, but provides sufficient context for an agent to invoke specific modes 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?
The input schema has 100% coverage with descriptions for all parameters. The description adds value by explaining how parameters relate to each type (e.g., videoUrl is needed for song/lyrics, playlistUrl for playlist). It clarifies the continuationToken is used for pagination, which the schema only names.
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 specifies that the tool interacts with YouTube Music resources, with distinct modes for search, autocomplete, song metadata, lyrics, album, artist, and playlist retrieval. It differentiates from sibling tools like stophy_search_videos by focusing on music-specific operations and returns types.
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 each 'type' operation and its required parameters (e.g., videoUrl for lyrics, albumUrl for album). It provides guidance on when to use each mode via the type enum. However, it does not directly compare to sibling tools or state when not to use this tool vs others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
stophy_search_videosASearch YouTube by keyword with optional filters. Returns items[] discriminated by type: video items have {id, videoUrl, title, author, description, duration, durationSec, viewCount, publishedAt, isLive, thumbnails}; short items have {id, shortUrl, title, viewCount, thumbnails}; channel items have {id, channelUrl, name, handle, subscriberCount, thumbnails}; playlist items have {id, playlistUrl, title, author, videoCount, thumbnails}. 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 to 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and destructiveHint; the description adds behavioral details such as the discriminated item types and pagination via continuationToken, going beyond 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 somewhat lengthy but well-structured, front-loading purpose, then return schema, then usage recommendations. Each sentence adds value, though it could be slightly more concise.
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 thoroughly explains the return structure for each item type and the continuationToken. With 7 parameters at 100% schema coverage and clear usage guidance, the description is fully complete 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 description coverage is 100%, so each parameter already has a description. The tool description does not add extra parameter semantics beyond what the schema provides; it focuses on return structure instead.
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 uses a specific verb ('search') and resource ('YouTube videos'), and clearly distinguishes from sibling tools like 'stophy_get_video' by stating it is not for fetching a specific video with a known URL.
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 provides when to use ('discovering videos on a topic, finding recent uploads'), when not to use ('fetching a specific video you already have the URL for'), and an alternative tool ('stophy_get_video').
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.
No comments yet. Be the first to start the discussion!
