hooklayer
Server Details
Viral-content intelligence for AI agents — 7 read-only MCP tools, evidence-layer scoring.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- khan-ashifur/hooklayer
- GitHub Stars
- 0
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.7/5 across 8 of 8 tools scored.
Each tool targets a distinct aspect of viral content creation: creator analysis, template discovery, voice matching, script/hook scoring, video search, trend detection, and remixing. No two tools overlap in purpose.
All tool names follow a consistent `verb_noun` pattern with underscores (e.g., `analyze_account`, `find_viral_template`, `score_hook`). Naming is predictable and descriptive.
8 tools is well-scoped for the server's purpose of viral content analysis and generation. Each tool fills a clear role without bloat, and the count aligns with typical MCP server sizes.
The tool set covers the full workflow: research (trend_pulse, search_videos), analysis (analyze_account, match_voice), generation (viral_remix, find_viral_template), and validation (score_hook, predict_virality). No obvious gaps for the domain.
Available Tools
8 toolsanalyze_accountARead-onlyIdempotentInspect
Deep intelligence on a TikTok or YouTube creator by handle. Returns viral DNA scores (viral_dna_score, replicability_score, originality_score, consistency_score, audience_fatigue), format fingerprint, top 5 recent videos with metadata (and transcripts on TikTok), content gaps, AND a recommended_chain field with pre-filled next tool calls. USE WHEN the user references a creator by @handle, asks "analyze X", wants competitor research, or needs creator context before generating content. The recommended_chain suggests which tools to call next (match_voice, trend_pulse, viral_remix) with parameters pre-filled — review and execute them as appropriate. Supports platform: "tiktok" (default, full transcript extraction) and "youtube" (channel Shorts analysis; transcript extraction lands in v1.1, current YouTube responses surface a partial-data flag noting this). Costs 5 credits. 1-hour cache per (handle, platform). TOOL HEALTH: Every response includes a quality field with a level (full | partial | degraded) and a reason. If quality.level is partial or degraded, you MUST flag this to the user explicitly in chat (e.g. "Heads up — this call returned partial data: ") before reporting any results. Never silently route around a degraded response. REPORTING: When you summarize this in chat, you MUST surface viral_dna.viral_dna_signals, viral_dna.replicability_signals, viral_dna.originality_signals (each as bullet lists with the cited evidence string verbatim) AND viral_dna.would_fail_because verbatim AND provenance.video_post_dates so the user can see freshness. Never hide the evidence array behind a paraphrase — these are the auditability layer.
| Name | Required | Description | Default |
|---|---|---|---|
| since | No | Optional ISO date (e.g. "2026-04-01"). Filter the candidate video pool to those posted on/after this date. Useful when the user asks "show me what they've done THIS month" — the route returns honest empty + warning when the filter matches 0, no credits charged. Use either `since` or `window`, not both. | |
| handle | Yes | Creator handle (with or without @ prefix) or YouTube channel ID. Examples: "@mrbeast", "mrbeast", "UCX6OQ3DkcsbYNE6H8uQQuVA". | |
| window | No | Recency sugar — same effect as `since` but takes a friendlier bucket. Maps to a since-cutoff at request time. Use either `since` or `window`, not both. | |
| platform | No | Platform to analyze. "tiktok" (default) returns full pipeline with transcripts. "youtube" analyzes the channel's recent Shorts via YouTube Data API + Innertube caption extraction (v1.1, 2026-06-10) — videos with captions disabled or geoblocked resolve to transcript: null and the response flags how many were extracted. Instagram ships in v1.2. | |
| recent_only | No | When true, hard-cap the candidate pool to videos posted in the last 90 days. Stricter than `window=90d` because it never falls through to archival data on a thin recent corpus. |
Output Schema
| Name | Required | Description |
|---|---|---|
| profile | No | Creator profile (handle, bio, followers, following, total_likes, total_videos) |
| from_payg | No | Whether credits came from pay-as-you-go balance |
| steal_map | No | Actionable elements to replicate from this creator |
| viral_dna | No | Five viral DNA scores (0-100 each) |
| content_gaps | No | Untapped content opportunities the creator is missing |
| recent_videos | No | Top recent videos with view counts, transcripts, and engagement |
| pattern_analysis | No | Content pattern breakdown (posting cadence, topic clusters) |
| credits_remaining | No | Credits remaining after this call |
| from_subscription | No | Whether credits came from subscription |
| recommended_chain | No | Suggested next tool calls with pre-filled parameters — advisory only, agent decides whether to execute |
| format_fingerprint | No | Dominant content format patterns (durations, styles, edit types) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, idempotentHint, destructiveHint) are fully consistent. Description adds behavioral details: costs 5 credits, 1-hour cache, TOOL HEALTH reporting with quality fields, and explicit reporting instructions. 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 comprehensive but well-structured with clear sections. Front-loaded with core function. Some redundancy (e.g., platform details repeated) but overall concise for the complexity.
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 edge cases (empty results, partial data, platform differences), health flagging, and detailed reporting instructions. Output schema exists, so return values are covered. 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?
100% schema coverage with detailed parameter descriptions. Description adds mutual exclusivity of since/window, platform-specific behavior, and recent_only strictness. Provides examples and clarifies defaults.
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 provides 'deep intelligence on a TikTok or YouTube creator by handle' and lists specific outputs like viral DNA scores and recommended_chain. It distinguishes from siblings by specifying use cases like competitor research and creator context.
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 says 'USE WHEN' with specific scenarios (referencing creator by handle, asking 'analyze X', competitor research, needing creator context). It also suggests follow-up tools in recommended_chain. Lacks explicit 'when not to use' but is otherwise clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_viral_templateARead-onlyIdempotentInspect
Find proven viral templates in a niche with example videos. Returns niche-fit ranked templates with hook pattern, format structure, average views, and example URLs. USE WHEN the user asks "what's working in [niche]", "give me templates I can copy", or wants concrete copyable structures rather than abstract trends. Pairs with viral_remix for end-to-end script generation. Costs 1 credit. Short niche names like "travel" or "fitness" are auto-mapped to canonical names — but passing the canonical name from the enum below is fastest.
| Name | Required | Description | Default |
|---|---|---|---|
| niche | Yes | One of the 17 supported niches. Loose names like "travel" or "fitness" are accepted but pass the canonical form when possible. | |
| region | No | Optional 2-letter ISO country code (US, GB, BR, JP, IN, PH, etc.). Threads to YouTube Search regionCode + TikTok niche query. Reddit niche signals are global and ignore this param. Pass when the user wants templates that resonate with a specific local audience. | |
| window | No | Recency filter. Drops example videos older than the window. Note: TikTok hashtag-corpus rows often lack timestamps and are excluded when window is set — surfaces as a quality warning so callers can decide whether to broaden. | |
| min_views | No | Optional filter — only return examples above this view count |
Output Schema
| Name | Required | Description |
|---|---|---|
| niche | No | The niche searched |
| from_payg | No | Whether credits came from pay-as-you-go balance |
| templates | No | Ranked viral templates with hook patterns and example URLs |
| credits_remaining | No | Credits remaining after this call |
| from_subscription | No | Whether credits came from subscription |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, openWorld, idempotent, and non-destructive behavior. Description adds credit cost, auto-mapping of loose niche names to canonical ones, a quality warning for the window parameter, and multi-platform behavior (Threads, TikTok, Reddit). 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?
Single paragraph but very dense. Every sentence adds value (usage, behavior, credit cost, param details). Could be slightly more structured (e.g., bullet points) but still efficient and clear.
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 4 params (1 required, 2 enums) and an output schema, the description covers purpose, usage, behavioral nuances, parameter details, and credit cost. No missing critical information.
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. Description adds value: explains auto-mapping of short niche names, clarifies region's multi-platform impact, and warns about window parameter excluding untimestamped TikTok rows. These go 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 tool finds proven viral templates in a niche, listing return elements (hook pattern, format structure, average views, example URLs). It distinguishes from siblings by mentioning pairing with viral_remix and contrasts with 'abstract trends'.
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 states when to use: when user asks 'what's working in [niche]', 'give me templates I can copy', or wants concrete structures. Also suggests pairing with viral_remix, providing clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
match_voiceARead-onlyInspect
Extract a creator's voice DNA from 3+ reference samples (URLs or text) and rewrite a draft in their voice. Returns voice profile (energy, humor, vocabulary, signature moves), reusable prompt instructions, the rewritten draft, AND a deterministic voice_metrics block: vocab_diversity_ttr (type-token ratio), filler_rate_per_100_words, avg_sentence_length_words, total_words, and signature_phrases[] (top 5 recurring 2-3-grams with counts). USE WHEN the user wants to write in another creator's style, has reference content to match, or chained from analyze_account.recommended_chain (which pre-fills reference_samples from the analyzed creator's videos). Costs 2 credits. TOOL HEALTH: Every response includes a quality field (level: full | partial | degraded, plus a reason string). If quality.level is partial or degraded, you MUST flag this to the user explicitly in chat ('Heads up — this call returned partial data: ') before reporting any results. Never silently route around a degraded response. REPORTING: When you summarize this in chat, you MUST surface the voice_metrics block as numbers — TTR, filler rate, avg sentence length, and the top signature_phrases with their counts. The qualitative voice_profile labels (energy, personality) alone are vibes; the numeric metrics are the reproducible signature. Cite both.
| Name | Required | Description | Default |
|---|---|---|---|
| draft | Yes | The text to rewrite | |
| reference_samples | Yes | At least 3 reference samples — TikTok/YouTube/Instagram URLs or raw text |
Output Schema
| Name | Required | Description |
|---|---|---|
| from_payg | No | Whether credits came from pay-as-you-go balance |
| voice_profile | No | Extracted voice DNA profile |
| rewritten_draft | No | The input draft rewritten in the matched voice |
| credits_remaining | No | Credits remaining after this call |
| from_subscription | No | Whether credits came from subscription |
| prompt_instructions | No | Reusable prompt to replicate this voice |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by disclosing the quality field (full/partial/degraded), the deterministic voice_metrics block, and the required reporting protocol for degraded responses. It does not contradict annotations; readOnlyHint is consistent with a generation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively long but well-structured: action first, then metrics, usage, health, and reporting. Every sentence adds value, though it could be more concise. Still front-loaded and clear.
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 (parameters, output schema, annotations), the description covers everything: what it does, how to use, output components, quality handling, and reporting. No gaps.
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 already fully describes both parameters (100% coverage). The description adds minimal extra meaning, only noting reference samples can be URLs or text and that they can be pre-filled from analyze_account. Baseline 3 is appropriate as the schema carries the burden.
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 extracts a creator's voice DNA from 3+ reference samples and rewrites a draft in their voice. It distinguishes itself from sibling tools by focusing on voice matching rather than analysis or trend detection.
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 tells when to use: when the user wants to write in another creator's style, has reference content, or is chained from analyze_account. Also mentions cost (2 credits) and provides a health-check quality field, setting clear expectations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
predict_viralityARead-onlyIdempotentInspect
Score a draft script for viral potential with a mitigation-aware adversarial second-pass. Returns optimistic_score (upstream self-grade), virality_score (adversarial headline), calibration_gap (disagreement between them), vectors_summary (counts of present vs mitigated attack vectors), recommendation ({verdict: SHIP|REWORK|NO-GO, reason}), score_range, viral DNA breakdown, signals[] with evidence, would_fail_because, calibration_check, and attack_vectors[] each tagged status: present|mitigated. USE WHEN the user has a finished draft and wants pre-publish verification, or chained after viral_remix to validate the generated script. Pass either a script string or a video URL. Costs 2 credits. TOOL HEALTH: response includes a quality field (level: full | partial | degraded, plus reason). If level is partial or degraded, flag it in chat before reporting. Never silently route around degraded data. REPORTING (v1.1.1 reframe — calibration gap is the value proposition, not a deficiency): lead with the recommendation.verdict and reason in plain language. Then frame the calibration_gap explicitly: "Every other AI scoring tool ships the OPTIMISTIC value of X without checking. The adversarial pass disagrees by GAP points and lands at VIRALITY_SCORE." Then surface vectors_summary as "X total, Y mitigated by the script, Z still present" and enumerate each PRESENT vector with severity + mitigation hint. Surface would_fail_because and signals[] last. NEVER report optimistic_score alone (recreates the self-grading loop). NEVER apologize for the adversarial number being lower — the gap IS the value. A 24-point gap means the check is doing its job; a 0-point gap means the check is rubber-stamping and worthless.
| Name | Required | Description | Default |
|---|---|---|---|
| niche | No | Niche context | |
| script | Yes | The draft script to predict on (or a video URL — auto-extracts transcript) |
Output Schema
| Name | Required | Description |
|---|---|---|
| blueprint | No | Retention diagnosis with weak seconds identified |
| from_payg | No | Whether credits came from pay-as-you-go balance |
| viral_dna | No | Hook type, structure, emotional triggers breakdown |
| share_reason | No | Why viewers would share this content |
| target_emotion | No | Primary emotion the content targets |
| virality_score | No | Overall virality prediction (0-100) |
| credits_remaining | No | Credits remaining after this call |
| from_subscription | No | Whether credits came from subscription |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds significant behavioral context: cost of 2 credits, TOOL HEALTH with quality field, and detailed reporting protocol (e.g., never silently route degraded data). This far exceeds the annotation burden.
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 verbose but well-structured. It front-loads the purpose and outputs, then provides clear usage and reporting guidelines. Every sentence adds value, though brevity could be improved.
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 (multiple outputs, TOOL HEALTH, reporting requirements), the description is remarkably complete. It covers all outputs, usage context, behavioral impacts, and agent reporting expectations. No gaps are evident.
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%, and the description adds clarifications: script can be a video URL for auto-transcription, and niche is optional. This adds value beyond the schema, though niche is not elaborated.
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 scores a draft script for viral potential using an adversarial second-pass. It explicitly distinguishes from siblings like viral_remix (generation) and other analytical tools. The verb 'score' and resource 'draft script' are specific, and the key output fields are listed.
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 when-to-use guidance: 'USE WHEN the user has a finished draft and wants pre-publish verification, or chained after viral_remix to validate the generated script.' This clearly differentiates from other use cases and mentions alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
score_hookARead-onlyIdempotentInspect
Score a TikTok/Reels/Shorts hook against proven viral patterns. Returns a 0-100 score, percentile rank, matched viral pattern, three rewritten versions at higher quality, a one-sentence verdict naming the closest calibration anchor (10/30/50/70/85/95), a 6-element signals[] array with evidence per sub-score, and a would_fail_because counterfactual. USE WHEN the user has a draft hook to validate, wants to A/B between alternatives, or needs to catch AI-generated slop before publishing. Pairs after viral_remix to verify the generated hook. Costs 1 credit. TOOL HEALTH: Every response includes a quality: { level: "full" | "partial" | "degraded", reason?: string } field. If quality.level is "partial" or "degraded", you MUST flag this to the user explicitly in chat ("Heads up — this call returned partial data: ") before reporting any results. Never silently route around a degraded response. REPORTING: When you summarize this in chat, you MUST surface (a) the score paired with the closest anchor from the why field, (b) the signals[] array as a bullet list with each evidence string verbatim — never paraphrase or drop signals, and (c) the would_fail_because field verbatim. If you score multiple hooks in sequence, also explicitly compare their signals[], not just the numeric scores — that's how the user judges which one wins.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The hook to score (3-200 chars typical) | |
| niche | No | Optional niche context (e.g. "Beauty & Skincare", "Finance & Business") | |
| platform | Yes | Target platform — affects pattern matching |
Output Schema
| Name | Required | Description |
|---|---|---|
| why | No | One-sentence verdict explaining the score |
| score | No | Hook quality score (0-100) |
| rewrites | No | Three rewritten versions at higher quality |
| breakdown | No | Sub-scores (0-100) for five quality dimensions |
| from_payg | No | Whether credits came from pay-as-you-go balance |
| strengths | No | What the hook does well |
| percentile | No | Percentile rank vs all scored hooks |
| weaknesses | No | What could be improved |
| pattern_match | No | Matched viral pattern name |
| credits_remaining | No | Credits remaining after this call |
| from_subscription | No | Whether credits came from subscription |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, etc. The description adds critical behavioral details: costs 1 credit, quality field with possible degradation, explicit reporting instructions for degraded responses, and requirement to surface signals and comparisons. No contradiction with 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 structured with clear sections (USE WHEN, TOOL HEALTH, REPORTING) and front-loaded with purpose. However, it is somewhat verbose, repeating details about the signals array multiple times. Could be slightly more concise but is still well-organized.
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 output schema exists (not shown but referenced), the description thoroughly explains return values, quality reporting, comparison logic, and user-facing reporting requirements. For a tool with 3 parameters and no nested objects, this is highly 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?
Schema coverage is 100% and includes descriptions for all parameters. The description adds no new meaning beyond the schema for parameters; it only restates constraints like '3-200 chars typical' which are already in the schema. 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 clearly states it scores a hook against viral patterns, returns a 0-100 score, percentile, matched pattern, rewritten versions, verdict, signals array, and counterfactual. It distinguishes from siblings by mentioning it pairs after viral_remix.
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 specifies when to use: 'USE WHEN the user has a draft hook to validate, wants to A/B between alternatives, or needs to catch AI-generated slop before publishing. Pairs after viral_remix to verify the generated hook.' Also provides alternatives context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_videosARead-onlyIdempotentInspect
Keyword search across the live TikTok corpus. Returns up to 20 videos matching a free-text query, ranked by engagement, with view/like/share/save/comment counts, hashtags, posted_at, author handle, and source URL. Optional filters: niche (drops videos whose description does not contain niche tokens), min_views, window ("24h"|"7d"|"30d"|"this-month"), and region (ISO country code: US, GB, BR, PH, JP, etc.). USE WHEN the user asks "find videos about X", "what is going viral with the keyword Y", or needs raw video discovery instead of niche-aggregated templates. Differs from find_viral_template: that one returns templates inferred from a niche; this one returns the raw video board for any query. Differs from trend_pulse: that one returns trending TOPICS; this one returns actual VIDEOS for a known query. Chain into viral_remix on any returned URL for a fresh script. Costs 2 credits. TOOL HEALTH: response includes a quality field (level: full | partial | degraded, plus reason). If level is partial or degraded, flag the reason verbatim to the user before reporting results. Zero-result responses come back with a warning AND no credits charged — surface the warning so the user can broaden their query.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max videos to return after filtering. Default 12, max 20. | |
| niche | No | Optional — only return videos whose description contains niche-related tokens. Loose niche strings work ("fitness", "Beauty & Skincare"). | |
| query | Yes | Free-text search term. Examples: "morning routine", "iphone case", "passive income". | |
| region | No | ISO country code (US, GB, BR, PH, JP, etc.). Note: corpus coverage varies by region — small regions may return zero results and a degraded quality flag. | |
| window | No | Recency filter. Maps to the closest ScrapeCreators date bucket AND applies a client-side cutoff for defense-in-depth. | |
| min_views | No | Optional view-count floor. Default 0. |
Output Schema
| Name | Required | Description |
|---|---|---|
| videos | No | |
| applied | No | Echo of the filters actually applied — useful for debugging when results look surprising |
| quality | No | |
| from_payg | No | |
| filtered_count | No | Videos returned after filtering + cap |
| upstream_count | No | Videos returned by upstream before any filtering |
| credits_remaining | No | Credits remaining after this call |
| from_subscription | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, idempotentHint, and not destructive. The description adds credit cost (2 credits), health quality field behavior, zero-result handling (warning and no charge), and region coverage issues. No contradictions with 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?
Front-loaded with core function and output, then parameter details, usage guidance, health warnings, and sibling distinctions. Slightly verbose but every sentence adds value; could tighten repetition of 'up to 20 videos'.
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 return fields, health status, credit cost, zero-result handling, chaining suggestion, and behavioral notes. Given the output schema exists and annotations cover safety, this description provides all necessary context for an AI agent to use the tool effectively.
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 3. Description adds context such as limit default (12, max 20), niche filtering logic, window date bucket mapping with client-side cutoff, and region coverage caveats, exceeding schema 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 states the tool performs keyword search across the live TikTok corpus, returns up to 20 videos with engagement metrics, and explicitly differentiates from sibling tools like find_viral_template and trend_pulse, specifying what each returns.
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 when-to-use scenarios are provided (e.g., 'find videos about X', 'what is going viral...'), and distinctions from siblings are clear. It also suggests chaining into viral_remix, but does not explicitly state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
trend_pulseARead-onlyIdempotentInspect
Surface what is actually peaking in short-form video right now for a niche. Returns 3 rising opportunities (format/hook/style/topic) with QUALITATIVE growth labels (e.g. "Rising", "Early signal", "Accelerating"), per-entry signal_strength (0-1, the QUANTITATIVE anchor), sources[] (Google Trends + YouTube velocity + Reddit hot + internal corpus), signal_window, plus 2 saturated patterns to avoid AND top-level provenance with cache_age_hours and cache_status. USE WHEN the user asks "what should I post about", "what's trending in [niche]", or before generating content for the first time. Pairs after analyze_account to validate a creator's formula against current trends. Costs 1 credit. 12-hour cache per niche. TOOL HEALTH: Every response includes a quality: { level: "full" | "partial" | "degraded", reason?: string } field. If quality.level is "partial" or "degraded", you MUST flag this to the user explicitly in chat ("Heads up — this call returned partial data: ") before reporting any results. Never silently route around a degraded response. REPORTING: When you summarize this in chat, you MUST cite the data_sources array verbatim and surface cache_status (fresh|stale) — the user needs to know if they're looking at live data. For each rising/saturated entry, cite the growth label and the signal_strength numeric anchor verbatim — DO NOT FABRICATE NUMERIC GROWTH PERCENTAGES. The upstream pipeline deliberately does not compute "+178.4%"-style growth rates (no ground-truth dataset supports it); if you see a numeric percentage in the response it came from upstream LLM hallucination, not the tool. Cite the qualitative label as written.
| Name | Required | Description | Default |
|---|---|---|---|
| niche | No | One of the 17 supported niches. Loose names like "travel" or "fitness" are accepted but pass the canonical form when possible. Omit for broadly applicable trends. | |
| region | No | Optional 2-letter ISO country code (US, GB, BR, JP, IN, PH, etc.). Threads to Google Trends geo + YouTube regionCode. Defaults to US when omitted. Reddit signals are global and ignore this param. |
Output Schema
| Name | Required | Description |
|---|---|---|
| niche | No | The niche these trends apply to |
| rising | No | Rising opportunities (format/hook/style) with qualitative growth labels + signal_strength numeric anchor (0-1) + suggestions |
| from_payg | No | Whether credits came from pay-as-you-go balance |
| saturated | No | Saturated patterns to avoid |
| credits_remaining | No | Credits remaining after this call |
| from_subscription | No | Whether credits came from subscription |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, and non-destructive behavior. The description adds crucial behavioral details: costs 1 credit, 12-hour cache per niche, quality field handling with explicit user-facing flagging instructions, and a warning against fabricating growth percentages due to upstream limitations. No contradiction with 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 long but every sentence earns its place. It is well-structured with clear sections: purpose, usage, cost, cache, health reporting, and guidelines. Despite its length, it is dense with actionable information and avoids redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema existence, the description focuses on behavioral and reporting context. It covers all necessary aspects: parameter constraints, usage scenarios, caching, quality handling, and reporting requirements. The presence of an output schema means return values are covered externally, making the description 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?
Schema coverage is 100% with both parameters described. The description adds value beyond schema by clarifying that loose niche names are accepted (e.g., 'travel' for 'Travel & Adventure'), explaining default region (US), and noting that Reddit signals ignore the region parameter. This enhances understanding for the agent.
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 explicitly states the tool's purpose: 'Surface what is actually peaking in short-form video right now for a niche.' It details the specific outputs including 3 rising opportunities with qualitative labels, signal_strength, sources, and saturated patterns. This clearly distinguishes it from siblings like analyze_account and find_viral_template.
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 when-to-use scenarios: 'USE WHEN the user asks "what should I post about", "what's trending in [niche]", or before generating content for the first time.' It also explains pairing with analyze_account and mentions cost and cache behavior, giving clear context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
viral_remixARead-onlyInspect
Take a viral source video and produce a fresh script that mirrors its viral DNA — same scene structure, same energy pattern, different topic. Returns the extracted formula, scene-by-scene script, camera shots, text overlays, and a verify_hook block prompting you to score the generated hook via score_hook. USE WHEN the user finds a video they want to copy the structure of, or chained from analyze_account.recommended_chain. Pass EITHER source_url (auto-extracts transcript) OR transcript directly — one is required. Costs 3 credits. NO SELF-RATING: viral_remix deliberately does NOT return a self-rated hook score. The script generator rating its own hook is structurally invalid (cardinal coupling). After every viral_remix call, you MUST call score_hook with the verify_hook.hook_text to get a structurally-independent quality signal before reporting to the user. Skipping this step is hiding the self-grading loop.
| Name | Required | Description | Default |
|---|---|---|---|
| niche | No | Optional niche hint | |
| my_topic | No | What the remix should be about. Default: same niche as original. | |
| source_url | No | TikTok/YouTube/Instagram URL — transcript will be auto-extracted | |
| transcript | No | Pre-extracted transcript (alternative to source_url, faster) |
Output Schema
| Name | Required | Description |
|---|---|---|
| overlays | No | Text overlay suggestions per scene |
| from_payg | No | Whether credits came from pay-as-you-go balance |
| hook_score | No | Self-rated hook quality score (0-100) |
| camera_shots | No | Phone-native camera direction per scene |
| fresh_script | No | Complete scene-by-scene script mirroring the source structure |
| credits_remaining | No | Credits remaining after this call |
| extracted_formula | No | The viral DNA formula extracted from the source |
| from_subscription | No | Whether credits came from subscription |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, openWorldHint), the description adds critical behavioral context: the tool does NOT return a self-rated hook score, explicitly warning against self-grading and requiring a follow-up call to score_hook. It also states the cost of 3 credits. No contradictions with 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 relatively long but well-structured, with core purpose upfront, then usage details, then behavioral warnings. While every sentence is necessary, it could be slightly more concise. However, it avoids redundancy and is clear.
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 (4 params, anyOf constraint, cost, required follow-up), the description covers purpose, when to use, parameter options, cost, behavioral constraints, and post-use requirement. It mentions return fields (formula, script, etc.) and notes that output schema exists, so no further explanation of return values is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters, but the description adds value by clarifying the anyOf constraint (source_url OR transcript required) and stating that my_topic defaults to the same niche as the original. This goes beyond the schema's basic 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 states the tool takes a viral source video and produces a fresh script with the same structure and energy pattern. It specifies the verb 'take' and 'produce', the resource (viral video), and the output (script, formula, etc.). It also distinguishes from siblings like analyze_account and score_hook by mentioning chaining from analyze_account.recommended_chain and the follow-up call to score_hook.
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 says 'USE WHEN the user finds a video they want to copy the structure of, or chained from analyze_account.recommended_chain.' It also explains how to pass parameters (source_url OR transcript), mentions costs (3 credits), and mandates calling score_hook after every call. 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.
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!