Unified social-media data across 10 networks: profiles, posts, search, comments, cross-search.
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.4/5 across 10 of 10 tools scored. Lowest: 3.8/5.
Most tools target distinct resources/actions, but there is some overlap: social_posts and reddit_history both return Reddit posts, social_search and search_all both perform searches, and snapchat_spotlight overlaps with social_posts for Snapchat. However, descriptions explicitly cross-reference and clarify when to use each, so misselection is unlikely.
The naming generally follows a snake_case pattern with a resource noun, using either a social_ prefix (social_posts, social_comments) or a platform-specific prefix (facebook_ads, reddit_history, threads_post). The exception is search_all, which breaks the pattern and is less noun-like compared to others.
With 10 tools covering profiles, posts, comments, search, and platform-specific features (ads, transcripts, spotlight), the count is well-scoped for a multi-platform social data retrieval server. Each tool serves a clear purpose and the set is not bloated.
The tool set covers core read operations across major platforms, including profile, posts, comments, and search. A notable gap is the lack of a generic way to fetch a single post by URL/ID across all platforms (only threads_post offers this specifically), which may require workarounds in some use cases.
facebook_adsFacebook / Meta Ad LibraryAMeta (Facebook/Instagram) Ad Library records as the unified Ad[] (id, pageName, adCreativeBody, adSnapshotUrl, startDate, currency, spend + impression ranges). Provide q OR pageId. GATED — needs operator-side FACEBOOK_ACCESS_TOKEN (with ads_read); returns credentials_required until set.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Free-text search across ad creative. Provide q OR pageId. | |
| limit | No | Max results, clamped 1-100. Default 25. | |
| pageId | No | Advertiser Page id. Provide q OR pageId. | |
| country | No | ISO-3166 alpha-2 country (upper-cased server-side). Default US. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only/idempotent/non-destructive, and the description adds the auth requirement and the 'credentials_required until set' behavior, which goes beyond the annotations. It doesn't mention pagination, but for a read-only retrieval tool this is sufficient extra context.
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 sentences: the first describes the resource and output, the second covers the query options and auth requirement. Every clause carries distinct, useful information with no filler, and the key details are front-loaded.
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?
With no output schema, the description provides a list of output fields (id, pageName, etc.), which is valuable. It also notes the gate/auth failure mode. It leaves limit clamping and country default to the schema, which is acceptable since the schema documents them, and the overall picture is complete enough for an agent to anticipate behavior.
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 descriptive parameter comments, so baseline is 3. The description repeats the q OR pageId constraint already present in the schema, but adds no new format details or clarifications. It does not add meaningful value beyond what the schema already provides.
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 identifies the tool as retrieving Meta Ad Library records, specifying the exact output shape (Ad[] with fields). It is distinct from sibling tools by naming the platform (Facebook/Instagram) and the specific data source, so an agent knows exactly when to select 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?
It gives direct usage instructions ('Provide q OR pageId') and states a key prerequisite (operator-side face_ACCESS_TOKEN with ads_read). It doesn't explicitly mention alternatives, but the platform-specific scope strongly implies when this tool is appropriate relative to the social_search siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
reddit_historyReddit full history (keyless)AKeyless full-history pull via Arctic Shift — a user's or subreddit's posts, or a keyword search across Reddit history, returned as the unified Post[]. Provide at least one of username, subreddit, or q. Optional before/after bound the window by epoch-seconds or ISO timestamp.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Keyword to search across history. | |
| after | No | Return items created after this epoch-seconds / ISO timestamp. | |
| limit | No | Max results, clamped 1-100. Default 25. | |
| before | No | Return items created before this epoch-seconds / ISO timestamp. | |
| username | No | Reddit username (without u/). | |
| subreddit | No | Subreddit (without r/). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, and the description adds key context: keyless access (no auth), reliance on Arctic Shift as the data source, and a unified Post[] return shape. No contradictions with annotations, and it goes beyond what annotations provide.
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, front-loading the core purpose ('Keyless full-history pull via Arctic Shift') before detailing scope and parameter requirements. Every sentence contributes value with no 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?
For a tool with three distinct modes, no output schema, and six optional parameters, the description covers the essential return shape (unified Post[]), parameter requirements, and time-bounding options. It omits details like pagination beyond the limit parameter and behavior when multiple filters are combined, but these are minor gaps given the schema and annotations.
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 the crucial requirement that at least one of username, subreddit, or q must be provided, which is not in the schema's required list. It also clarifies the before/after window accepts both epoch-seconds and ISO timestamps, though the schema already indicates this.
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 identifies the tool as a keyless full-history pull via Arctic Shift, covering user posts, subreddit posts, or keyword search. It distinguishes itself from siblings like social_search or social_posts by emphasizing 'full history' and 'keyless' access.
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: 'Provide at least one of username, subreddit, or q' and optional before/after bounds. It does not explicitly name alternative tools, but the full-history and keyless framing implies when it is appropriate compared to more limited search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_allSearch every network at onceAThe wedge no incumbent offers: fan one search query out across the requested platforms (default: all keyless, non-disabled) in parallel, merge the unified Post[], and tag each result with its platform. Gated / disabled / unsupported / throttled engines are listed under "skipped" with an honest reason — the call still returns whatever came back.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Search query. | |
| limit | No | Max results, clamped 1-50. Default 10. | |
| platforms | No | Comma-separated subset of platforms to query (e.g. "tiktok,youtube,threads"). Omit for all keyless, non-disabled platforms. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only/non-destructive behavior. The description adds valuable behavioral details: parallel execution, merging results into Post[], tagging platform, and the 'skipped' list with reasons for gated/disabled/unsupported/throttled engines. It also discloses partial results are returned even if some fail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence, front-loaded with purpose. The phrase 'The wedge no incumbent offers' is marketing fluff rather than functional content, slightly reducing conciseness, but the rest is efficient and information-rich.
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, so the description must explain return values. It covers the merged Post[] with platform tags, the 'skipped' list with reasons, and the guarantee of returning whatever results came back – sufficient for an aggregator tool of this 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 the baseline is 3. The description adds no new parameter meaning beyond the schema; it mentions 'default: all keyless, non-disabled' for platforms, but the schema already says 'Omit for all keyless, non-disabled platforms.' The 'clamped 1-50' for limit is already encoded in min/max.
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 the action: 'fan one search query out across the requested platforms' and 'merge the unified Post[]'. It distinguishes itself from siblings by covering multiple platforms at once, and the unique scope is evident.
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 conveys a clear use case: cross-platform search in parallel. It implies this is the go-to for multi-platform queries, though it doesn't explicitly state when to prefer sibling tools for single-platform searches or provide exclusions. Context is 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.
snapchat_spotlightSnapchat creator Spotlight feedAA creator's public Snapchat Spotlight feed as the unified Post[] with real view/comment/share counts. Keyless.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results, clamped 1-50. Default 20. | |
| username | No | Account handle / username (without @). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool safe (readOnly, idempotent, non-destructive). The description adds 'public' and 'Keyless' to clarify access needs, and 'real view/comment/share counts' specifies the metrics returned. This goes beyond annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that packs the purpose, scope, output type, and access requirement with 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 simple two-parameter read-only tool with complete schema and strong annotations, the description is adequate. It could mention pagination or order of results, but 'unified Post[]' hints at a standard list format.
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 both parameters completely, including the clamping behavior for limit and the '@' expectation for username. The description adds no additional parameter-level details, so the schema is sufficient.
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 the resource (a creator's public Snapchat Spotlight feed) and the output (unified Post[] with real view/comment/share counts). It distinguishes from sibling tools by mentioning 'Keyless' and the platform-specific focus, but it lacks an explicit action verb like 'fetches' or 'retrieves'.
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?
Usage is implied: the description notes the feed is public and keyless, suggesting it is appropriate when no authentication is required. However, it does not explicitly state when to choose this tool over alternatives such as social_posts or social_profile.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
social_postsGet an account's recent postsAAn account's recent posts / videos / tweets / threads / pins as the unified Post[] schema (id, url, author, text, createdAt, like/comment/share/view counts, mediaType, mediaUrls, hashtags), tagged with its platform. Keyless on Instagram, TikTok, YouTube, Pinterest, Snapchat, and Threads. Twitter/X, Reddit, and Facebook need operator-side credentials; LinkedIn is quarantined. For a keyless Reddit history pull use reddit_history.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results, clamped 1-100. Default 20. | |
| cursor | No | Opaque pagination cursor from a previous response (where the platform supports paging). | |
| platform | Yes | Target social network. | |
| username | Yes | Account handle / username (without @). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety profile is covered. The description adds valuable context beyond annotations: platform-specific credential requirements, LinkedIn quarantine, and the unified output schema. It does not cover error handling or rate limits, so a 4 is appropriate rather than 5.
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 and information-dense, leading with the core function, then enumerating the output schema, keyless platforms, credential requirements, and a specific alternative in a few sentences. No redundant or filler content.
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 multi-platform read-only tool with complexity around credentials and output unification, the description is exceptionally complete. It explicitly describes the unified Post[] schema, lists which platforms require credentials, flags LinkedIn as quarantined, and even names the sibling tool for a specific use case. This gives an agent sufficient context to select and invoke 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 description coverage is 100%, with all four parameters well-documented including the platform enum, username without '@', limit clamping, and cursor semantics. The description adds platform context that indirectly affects the 'platform' parameter but does not alter understanding of parameter syntax or formats, so the baseline 3 applies.
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 it retrieves an account's recent posts across multiple platforms with a unified Post[] schema, listing exact fields. It distinguishes itself from sibling tools by explicitly naming reddit_history as an alternative for keyless Reddit pulls, and the title 'Get an account's recent posts' is specific.
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 states which platforms are keyless (Instagram, TikTok, YouTube, Pinterest, Snapchat, Threads) and which require operator-side credentials (Twitter/X, Reddit, Facebook), and notes LinkedIn is quarantined. It also directly recommends using reddit_history for keyless Reddit access, providing 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.
social_profileGet a social profileAFetch one account profile from any supported network as the unified Profile schema (id, username, displayName, bio, url, followers, following, postCount, verified, avatarUrl, externalUrl), tagged with its platform. Keyless on Instagram, TikTok, YouTube, Pinterest, Snapchat, and Threads. Twitter/X, Reddit, and Facebook need operator-side credentials (returns credentials_required until set); LinkedIn is quarantined (platform_disabled).
| Name | Required | Description | Default |
|---|---|---|---|
| platform | Yes | Target social network. | |
| username | Yes | Account handle / username (without @). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent hints in annotations, the description discloses credential requirements (keyless vs credentials_required), platform disabling (platform_disabled for LinkedIn), and enumerates the exact fields returned in the unified Profile schema. This provides meaningful 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, with three sentences each serving a purpose: stating the core function, listing the schema fields, and covering platform-specific execution. No unnecessary words or repetition.
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 two-parameter read tool with no output schema, the description is fully self-contained: it explains what the tool returns (unified Profile schema), how to invoke it (platform and username), and important operational caveats (credentials and disabled platform). The agent has everything needed to select and 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?
The input schema already describes both parameters fully (platform enum and username format), achieving 100% schema coverage. The description adds no additional parameter-level meaning beyond what the schema provides, so the baseline 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 starts with 'Fetch one account profile from any supported network', clearly stating the action and resource. It also specifies the unified Profile schema and platform tagging, which distinguishes it from sibling tools like social_posts or social_comments.
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 context on platform availability: it names which platforms are keyless, which require credentials, and which are disabled. However, it does not explicitly name alternatives or state when not to use this tool, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
social_searchSearch one network for postsASearch a single network for posts matching a query, returned as the unified Post[] schema and tagged with its platform. Keyless on TikTok, YouTube, and Pinterest. Instagram, Twitter/X, Reddit, and Facebook need operator-side credentials (returns credentials_required until set). Snapchat and Threads do not support keyless search (returns not_supported); LinkedIn is quarantined. To fan one query across every network at once, use search_all.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Search query. | |
| limit | No | Max results, clamped 1-100. Default 20. | |
| cursor | No | Opaque pagination cursor from a previous response (where the platform supports paging). | |
| platform | Yes | Target social network. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, idempotent, and non-destructive. The description adds valuable behavioral context beyond annotations: platform-specific outcomes like keyless availability, credentials_required, not_supported, and LinkedIn quarantine, plus the unified Post[] return shape and platform tagging.
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?
Three sentences, front-loaded with the core action, followed by compact platform-specific notes and a sibling pointer. No wasted words; each 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?
Given no output schema, the description covers the return shape (Post[] with platform tag) and error/edge states (credentials_required, not_supported, quarantine). It also points to the alternative tool. The only missing minor detail is pagination mechanics, but the schema's cursor parameter and descriptions suffice.
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 covers all parameters with descriptions (100% coverage), so baseline is 3. The description enriches the platform parameter semantics by detailing which platforms are keyless, require credentials, don't support keyless, or are quarantined. This adds value beyond the enum list.
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 opens with a specific verb+resource+scope: 'Search a single network for posts matching a query.' It clearly distinguishes from the sibling search_all tool by explicitly naming it as the multi-network alternative, and the mention of 'single' network sets the boundary.
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 this tool vs search_all, and offers per-platform operational details (keyless support, credential requirements, not_supported, quarantine). This goes beyond generic advice, telling the agent exactly what to expect for each platform.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
threads_postThreads post by shortcodeAFetch a single thread by shortcode or URL, including its replies, as the unified Post (with replies). Provide code OR url. Keyless.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Full thread URL. Provide code OR url. | |
| code | No | Thread shortcode. Provide code OR url. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive. The description adds useful behavioral context beyond annotations: that replies are included, the response is a unified Post, and no API key is required. It does not discuss edge cases like invalid shortcodes or rate limits, but adds meaningful value.
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 extremely concise, comprising a single sentence plus two short clauses. It front-loads the main action and includes only essential details without unnecessary 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?
For a simple read-only retrieval tool with strong annotations and fully documented parameters, the description covers the key aspects: what is fetched, how to identify it, and an access requirement ('Keyless'). It does not provide a detailed output structure, but no output schema exists and the tool's simplicity reduces the need.
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% and both parameters are already self-explanatory ('Full thread URL', 'Thread shortcode') with the same 'Provide code OR url' guidance. The description repeats this but does not add new meaning such as which parameter to prefer or behavior when both are supplied.
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 ('Fetch'), identifies the resource (a single thread on Threads by shortcode or URL), and specifies scope ('including its replies, as the unified Post (with replies)'). This clearly distinguishes the tool from siblings like social_posts or social_comments.
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?
It gives clear context for use (provide code or URL, keyless access) and implies it is for fetching a specific Threads thread rather than general social posts. However, it does not explicitly name alternative tools or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
youtube_transcriptYouTube transcript / caption languagesAAvailable caption-language list (and cue segments where retrievable) for a YouTube video. Provide url OR videoId. Keyless. NOTE: actual cue text is BotGuard-gated keyless, so it is reported honestly (available:false, empty segments) rather than fabricated.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | YouTube watch URL. Provide url OR videoId. | |
| lang | No | Preferred caption language (BCP-47, e.g. "en"). | |
| videoId | No | 11-char video id. Provide url OR videoId. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a critical behavioral trait beyond annotations: actual cue text is BotGuard-gated keyless, and the tool reports 'available:false' or empty segments rather than fabricating data. This adds important context about reliability and honesty, exceeding what readOnlyHint and idempotentHint already convey.
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, front-loaded with the core purpose, followed by usage and a concise limitation note. Every word earns its place, with no redundancy or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given only three optional parameters and no output schema, the description adequately explains what the tool returns (caption-language list and cue segments where retrievable) and how it behaves when not retrievable (available:false, empty segments). This covers the essential information for correct selection and use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all three parameters. The description's 'Provide url OR videoId' adds exclusivity that is also already stated in the schema's parameter descriptions, so it does not significantly enhance parameter understanding 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 returns available caption-language list and cue segments for a YouTube video, specifying the resource (YouTube video) and scope (caption languages). It is distinct from sibling tools, which are all social media related, so there is no ambiguity about what this tool does.
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 usage instruction 'Provide url OR videoId' and notes the keyless access, giving clear context on how to invoke it. It does not explicitly mention alternatives, but the sibling tools are unrelated (social media), so the intended use case is implied and unambiguous.
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!
Sign in to create a connector for this server.
social_commentsGet comments / replies on a postAComments / replies on one post as the unified Comment[] schema, tagged with its platform. Provide url OR postId. Keyless on TikTok, YouTube, and Threads (and a single tweet via syndication on Twitter/X). Instagram, Reddit, and Facebook need operator-side credentials; Snapchat comments are not supported keyless; LinkedIn is quarantined.
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses extensive behavioral details beyond annotations: which platforms support keyless access (TikTok, YouTube, Threads, Twitter/X via syndication), which require credentials (Instagram, Reddit, Facebook), Snapchat's lack of keyless support, and LinkedIn quarantine. These are non-obvious and add significant value.
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 sentences, front-loaded with the core purpose, followed by a compact enumeration of platform conditions. No redundant or unnecessary text.
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?
Covers core usage and major platform caveats, but omits pagination behavior (cursor) and rate limits. Given the parameter schema documents the cursor and the annotations indicate read-only/idempotent behavior, this is acceptable for a read-only 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?
Adds the 'url OR postId' constraint to clarify mutual exclusivity, which is not fully explicit in the schema. Also mentions the unified Comment[] schema. Since the schema already describes all parameters, this is incremental but meaningful.
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 'Comments / replies on one post' with a specific resource (post) and output ('unified Comment[] schema'), distinguishing it from sibling tools like social_posts or social_search.
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 clear usage context: 'Provide url OR postId' and enumerates platform-specific credential requirements. It does not explicitly name alternative tools, but the single-post scope and platform caveats imply appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.