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.5/5 across 9 of 9 tools scored.
Each tool has a clearly distinct purpose: analyzing creators, creating blueprints, finding templates, matching voice, scoring virality, scoring hooks, searching videos, researching trends, and remixing. No two tools overlap significantly.
Most tools follow a verb_noun pattern (e.g., analyze_account, score_hook, search_videos), but a few deviate like brief_to_blueprint (noun phrase) and trend_pulse (compound noun). Overall, names are descriptive and consistent in style.
With 9 tools, the server is well-scoped for short-form content creation analysis and assistance. Each tool adds unique value without redundancy or excessive specialization.
The tool set covers key content creation workflows: creator analysis, trend research, template discovery, hook and script scoring, voice matching, video search, and remix. No obvious gaps for its intended domain.
Available Tools
9 toolsanalyze_accountARead-onlyIdempotentInspect
Analyze a TikTok, YouTube, or Instagram creator by handle or channel ID. Returns viral DNA scores (viral_dna_score, replicability_score, originality_score, consistency_score, audience_fatigue), content patterns, format fingerprint, top recent videos with transcripts, content gaps, and recommended next research steps. Use when the user asks to analyze a creator, account, channel, or competitor. Supports TikTok (full transcript extraction), YouTube (Shorts and longform analysis with captions when available), and Instagram (Reels with best-effort transcripts). REPORTING: LEAD with headline_insight.wow — the single quantified lever the creator most needs to hear (the biggest performance gap across length/hook/format/cadence), stated FIRST, before any score — then headline_insight.so_what. That is the value-add "wow" opener.
| 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 recent Shorts via YouTube Data API + Innertube caption extraction — videos with captions disabled or geoblocked resolve to transcript: null. "instagram" (shipped 2026-07-06) fetches the creator's reels via ScrapeCreators Instagram API + best-effort reel transcripts on the top 5 — Instagram data lacks lifetime totalLikes so that field defaults to 0. | |
| 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 already declare readOnlyHint=true, idempotentHint=true. The description adds details like platform limitations (Instagram totalLikes defaults to 0, YouTube transcripts may be null) and reporting format (headline_insight order), which are beyond annotations. No 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 lengthy and includes detailed reporting instructions that could be placed elsewhere (e.g., output schema). It is front-loaded with purpose but contains extraneous formatting guidance.
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 (5 params, platforms, output schema, annotations), the description covers all essential aspects: purpose, parameters, platform behaviors, limitations, and reporting format, leaving no obvious 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 coverage is 100%, so baseline is 3. The description adds value by explaining since vs. window, handle examples, platform defaults, and recent_only behavior, enhancing 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 analyzes TikTok, YouTube, or Instagram creators by handle/channel ID and lists specific outputs (viral DNA scores, content patterns, etc.), distinguishing it from sibling tools focused on templates or voice matching.
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 says 'Use when the user asks to analyze a creator, account, channel, or competitor' and provides platform-specific details. It lacks explicit when-not-to-use instructions but gives clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
brief_to_blueprintARead-onlyInspect
The 24-48hr Panic Button. Turns a brand brief that just landed into a defensible one-page creative blueprint the manager can forward to the creator AND to the brand contact — hook + template + hashtag combo + trend velocity check + shoot instructions, in ONE call. USE WHEN a brand emails "product arrived, need content in 48 hours" and the manager needs a defensible direction NOW with no research time. Chains find_viral_template + trend_pulse + score_hook + predict_virality upstream but exposes them as one MCP tool so agents don't stitch. Owns the "brief-just-landed" panic ritual — the 2-minute moment right after a brand sends a brief when a creator manager needs a defensible content direction so they can hand a creator a plan today and shoot tomorrow. Cost 7 credits (bundle discount vs firing the chain manually). REPORTING: When you summarize this in chat, you MUST lead with blueprint.verdict (GO | NEEDS_MORE_DATA | NO_GO) and verdict_reason verbatim. Then surface blueprint.hook.text + blueprint.hook.trend_still_alive (up-slope | plateau | fading | unknown) — those are the two lines managers forward. If quality.level != "full" flag the reason explicitly before reporting the blueprint. If blueprint.verdict is NEEDS_MORE_DATA or NO_GO, the blueprint is a starting point, NOT a shippable direction — say so.
| Name | Required | Description | Default |
|---|---|---|---|
| niche | Yes | One of the 17 supported niches. Loose names like "beauty" or "fitness" are auto-mapped. | |
| region | No | Optional 2-letter ISO country code (US, GB, CA, etc.). Threads to niche + trend upstreams. | |
| product | Yes | What the brand sent (name + one line, e.g. "Athletic Greens AG1 travel packs — 30-count individual sachets for travel") | |
| platform | No | Target platform. Both TikTok and Instagram Reels supported (shipped 2026-07-06). When set to "instagram", the product-corpus lookup runs against Instagram Reels via ScrapeCreators, and the creator context (if creator_handle passed) fetches Instagram reels. Default: tiktok. | |
| creator_handle | No | Optional creator handle (with or without @). If provided, the blueprint hook and script match THEIR voice patterns from recent videos. Highly recommended — a blueprint without creator context is generic. | |
| deadline_hours | No | How many hours until the video must be posted. Default 48. Affects trend-still-alive scoring — a 24-hour deadline needs a trend on the up-slope, not one that just plateaued. | |
| product_category | Yes | Umbrella category (e.g. "greens powder", "sunscreen", "protein bar") |
Output Schema
| Name | Required | Description |
|---|---|---|
| as_of | No | |
| stats | No | |
| applied | No | Echo of parameters resolved after canonicalization |
| quality | No | |
| success | No | |
| blueprint | No | |
| provenance | No | |
| credits_remaining | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses credit cost (7 credits, bundle discount), reporting format (must lead with verdict and reason, surface specific fields), and behavior when quality.level is not full or verdict is NEEDS_MORE_DATA/NO_GO. Annotations provide readOnlyHint and openWorldHint, and description adds significant behavioral context 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 front-loaded with the panic button concept and structured into clear sections: use case, what it does, cost, reporting. However, it is slightly verbose with redundant phrasing (e.g., 'the 2-minute moment part') and the reporting section could be shortened. Still efficient and readable.
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 7 parameters, 3 required, full schema coverage, output schema exists, and annotations present, the description covers purpose, usage, behavioral traits, and reporting. It explains how it chains other tools and handles edge cases (non-full quality, verdict types). Agent can correctly invoke and interpret results.
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 baseline is 3. The description does not add parameter-level details beyond what the schema already provides (e.g., niche auto-mapping, deadline_hours affecting trend scoring). Features are adequately documented in 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 it turns a brand brief into a one-page creative blueprint with specific components (hook, template, hashtag, trend velocity, shoot instructions). It distinguishes from siblings by noting it chains find_viral_template + trend_pulse + score_hook + predict_virality into a single tool, avoiding manual stitching.
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 'USE WHEN a brand emails product arrived, need content in 48 hours' and 'manager needs defensible direction NOW with no research time'. Also implies alternatives by mentioning it chains other tools, so agents can use those individually if not in a panic scenario.
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 templates ranked by performance, including hook patterns, format structures, average views, and example URLs. Use when the user asks what's working in a niche or wants concrete copyable structures. Supports 17 niches with optional angle narrowing via query parameter for more specific results (e.g., "postpartum strength" within Fitness).
| 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. | |
| query | No | Optional angle narrowing within the niche. E.g. niche="Fitness & Health" + query="postpartum strength" returns only postpartum-strength templates, not generic gym. Templates are scored by query-token match against title+description+hashtags; zero-match templates are dropped. Leave empty for niche-wide top templates. | |
| 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. | |
| platform | No | Platform to source templates from. "tiktok" (default) uses the full niche-aggregator (YouTube + Reddit + TikTok hashtags). "instagram" (2026-07-06) is keyword-search-only — the Instagram niche-aggregator isn't plumbed yet, so `query` becomes REQUIRED on IG. Output rubric_version signals which path ran: find_viral_template.v1 (main), .v2-keyword-fallback (TikTok fallback), .v3-instagram-keyword-only (IG-only path). | |
| 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 indicate readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds substantial behavioral context: query scoring logic, region behavior (different for YouTube vs. Reddit), window excluding TikTok rows, platform path differences (Instagram requires query, output rubric_version), and quality warnings. 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?
Two well-structured paragraphs: first gives a clear summary of purpose and output; second details parameter usage. Every sentence adds value, with front-loaded purpose and no redundancy. The description efficiently covers complex interactions without excessive length.
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 (6 parameters, multiple platforms, region/window interactions, output schema), the description thoroughly explains all behaviors, edge cases (e.g., TikTok timestamp lack, Instagram path requirement), and provides warnings (quality warning). It is fully sufficient for an agent to correctly select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 6 parameters. The description significantly extends meaning: query 'scored by query-token match... zero-match dropped', region 'Threads to YouTube Search... Reddit ignores', window 'excludes TikTok rows lacking timestamps... quality warning', and platform details different paths and output version. These add value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's purpose: 'Find proven viral templates in a niche with example videos.' It details outputs (hook patterns, format structures, average views, example URLs) and distinguishes from siblings like search_videos and trend_pulse by focusing on 'templates ranked by performance' rather than general 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?
The description provides clear when-to-use guidance ('when the user asks what's working in a niche or wants concrete copyable structures') and explains optional parameters for narrowing (query, region, window, platform). It does not explicitly exclude use cases or mention alternatives, but the context from sibling tools implies alternatives exist.
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 reference samples and rewrite a draft in their style. Requires at least 3 reference samples (video URLs or text). Returns voice profile (energy, humor, vocabulary, signature phrases), reusable prompt instructions, and the rewritten draft. Use when the user wants to write in another creator's style or match a specific voice.
| 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 adds behavioral details beyond annotations, such as requiring at least 3 reference samples and listing return items (voice profile, prompt instructions, rewritten draft). Annotations (readOnlyHint=true) align with the non-destructive nature.
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 and well-structured: a single sentence stating purpose, followed by requirements and outputs. No 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?
The description explains what the tool returns (voice profile, prompt instructions, rewritten draft) despite having an output schema. It covers all necessary context for a tool with two required parameters and no nested objects.
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 description adds meaning to both parameters: draft is 'the text to rewrite', reference_samples includes minimum 3 and valid sources (URLs or raw text). Schema coverage is 100%, but the description clarifies usage.
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 tool's purpose: extracting a creator's voice DNA and rewriting a draft. It distinguishes from sibling tools like 'analyze_account' or 'score_hook' by focusing on voice mimicry.
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 when to use the tool: 'when the user wants to write in another creator's style or match a specific voice.' It does not mention when not to use, but the context is clear.
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 adversarial verification. Returns a virality score, recommendation (ship/rework/no-go), viral DNA breakdown with evidence, attack vectors analysis, and calibration metrics. Use when the user has a finished draft and wants pre-publish verification. Pass either a script string or a video URL.
| 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 indicate readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds valuable context: it involves adversarial verification, returns viral DNA breakdown with evidence, attack vectors, and calibration metrics. No contradictions. Only minor gap is no mention of response size or pagination, but output schema exists.
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, each serving a purpose: action, output components, usage guidance. No filler. Front-loaded with main action.
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 2 parameters, output schema exists, and annotations cover safety, the description provides sufficient context for invoking the tool. It explains what the output contains and when to use. Could be more specific about output format but output schema fills that gap.
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 both script (auto-extract from URL) and niche (just 'Niche context'). The description echoes the script param's dual purpose but does not explain niche. Since schema already covers parameters, description adds minimal additional meaning.
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 with adversarial verification, specifying it returns a score, recommendation, breakdown, etc. It distinguishes from siblings by explicitly recommending use on finished drafts for pre-publish verification, contrasting with tools like find_viral_template or 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 provides explicit when-to-use guidance: 'Use when the user has a finished draft and wants pre-publish verification.' It also explains input options (script string or video URL). Lacks explicit when-not-to-use or alternative tool mentions, but the context is clear enough.
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, or Shorts hook against proven viral patterns. Returns a 0-100 score, percentile rank, matched pattern, strengths, weaknesses, and three improved hook variations. Use when the user has a draft hook to validate, wants to compare alternatives, or needs feedback before publishing.
| 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, openWorldHint, idempotentHint, and destructiveHint, indicating a safe, idempotent read operation. The description adds beyond this by detailing the return structure (score, percentile rank, patterns, strengths, weaknesses, variations) and platform-specific pattern matching.
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: first describes function and output, second provides usage guidance. No wasted words, front-loaded with the most important 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 the tool has 3 parameters, an output schema (not provided but noted), and clear annotations, the description covers purpose, usage, behavioral details, and parameter semantics comprehensively. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description adds value by specifying typical character length for 'text' (3-200 chars), clarifying 'niche' as optional context, and noting 'platform' affects pattern matching.
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 verb 'score' and the resource 'hook', specifying it works for TikTok, Reels, or Shorts. It distinguishes from siblings like 'find_viral_template' and 'predict_virality' by focusing on scoring hooks against viral patterns.
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 the user has a draft hook to validate, wants to compare alternatives, or needs feedback before publishing.' No explicit when-not-to-use or alternatives, but the positive guidance is clear and context-specific.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_videosARead-onlyIdempotentInspect
Search for short-form videos by keyword across TikTok or Instagram. Returns up to 20 videos ranked by engagement, with view counts, likes, shares, comments, hashtags, author info, and URLs. Use when the user asks to find videos about a topic or keyword. Supports optional filters for niche, minimum views, recency window, and region.
| 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. | |
| platform | No | Which platform to search. "tiktok" (default) hits ScrapeCreators TikTok keyword search. "instagram" (2026-07-06) hits Instagram Reels search — note IG upstream ignores region/date_posted params, so region enforcement is client-side only (region_verified_count in the response tells you how many results verifiably matched). | |
| 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 declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. Description adds important behavioral details: result ranking by engagement, platform-specific behavior (Instagram ignores region/date_posted, client-side enforcement), and region coverage variability. This adds value 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?
Four sentences that are clear and well-ordered, but slightly longer than necessary. Key information is front-loaded and every sentence adds value. A minor conciseness opportunity.
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 7 parameters, output schema, and rich annotations, the description covers purpose, return structure, usage context, and key behavioral nuances (platform differences, region effects). No gaps are apparent for an agent to select and invoke 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%, so the baseline is 3. The description does not add further parameter-specific meaning beyond the schema's own descriptions. It remains at the baseline.
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 ('short-form videos'), details the platforms (TikTok, Instagram), return fields (view counts, likes, etc.), and result limit (up to 20). It clearly differentiates from sibling tools like analyze_account or 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?
Explicitly states 'Use when the user asks to find videos about a topic or keyword,' giving a clear context. Does not explicitly exclude alternatives, but sibling tools cover different intents, so guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
trend_pulseARead-onlyIdempotentInspect
Research what is currently gaining traction in short-form content for a specific niche. Returns rising opportunities (formats, hooks, styles, topics) with growth signals, data sources, and saturated patterns to avoid. Use when the user asks what to post about, what's trending in a niche, or needs to validate a content idea against current trends. Supports 17 niches and optional region filtering.
| 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. | |
| deadline_hours | No | Optional (2026-07-06 magic-genie ritual): how many hours until the video posts. When set, each rising trend gets a trend_status (up-slope | plateau | fading | unknown) AND a deadline_verdict (safe | risky | no-go) so managers can answer "will this trend still be alive when the video posts?" without eyeballing the growth label. Use this on every brief-just-landed call — it turns trend_pulse from "what's trending" into "what's SAFE to bet on for MY post window." |
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 readOnlyHint=true and destructiveHint=false indicate a safe read operation. The description adds significant behavioral context: it returns rising opportunities with growth signals, data sources, and saturated patterns to avoid; explains that Reddit signals are global; and describes the special behavior of deadline_hours which adds trend_status and deadline_verdict. 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 concise (about 100 words), front-loaded with purpose, then output components, usage, and parameter details. Every sentence adds value, with no wasted words. The structure is logical and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 optional parameters and an output schema (indicated by context), the description covers its purpose, usage, and parameter behaviors thoroughly. It mentions return elements (growth signals, data sources, saturated patterns) and special behaviors. No gaps are apparent for an AI agent to correctly select and invoke the 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%, but the description adds substantial meaning: for niche, it explains loose names are accepted; for region, it details how it maps to Google Trends and YouTube, with a default; for deadline_hours, it explains its transformative effect on output. This goes well beyond the 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 researches short-form content trends for a niche and returns rising opportunities with growth signals. It uses specific verbs ('Research', 'Returns') and specifies the resource (short-form content trends). It distinguishes from sibling tools like 'find_viral_template' and 'predict_virality' by focusing on trend research rather than template or virality prediction.
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 when to use the tool: 'when the user asks what to post about, what's trending in a niche, or needs to validate a content idea against current trends.' It also notes supported niches and optional region filtering. It does not explicitly list when not to use or give alternatives, but the context is clear and the sibling tools are listed for reference.
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 video and produce a fresh script that mirrors its structure and energy pattern for a new topic. Returns the extracted formula, scene-by-scene script with voiceover and visuals, camera directions, and text overlays. Use when the user finds a video they want to replicate the structure of. Pass either a video URL (TikTok, YouTube, or Instagram) or a transcript directly.
| 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 |
| verify_hook | No | Hook + instruction to chain into score_hook for a structurally-independent score (the script generator deliberately does NOT self-rate) |
| camera_shots | No | Phone-native camera direction per scene |
| fresh_script | No | Complete scene-by-scene script mirroring the source structure |
| cta_archetype | No | Which CTA archetype the generator picked. Comment_gate is the failure-mode default for AI script generators; rotation tells you whether the prompt is working. |
| ugc_authenticity | No | Tripwire for ad-shaped drift. Detected via regex on the produced script, not the model self-grade. If level=ad_leaning, surface to the user before shipping. |
| 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 |
| structural_skeleton | No | Which structural skeleton the generator used (confession_to_result, mistake_to_correction, etc). Surfaces rotation across the fleet. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, indicating no side effects. The description adds behavioral context by detailing the output (extracted formula, scene-by-scene script, camera directions, text overlays) and input options (URL or transcript), providing useful information beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with only three sentences, each serving a distinct purpose: stating the action and output, specifying when to use, and explaining input options. No unnecessary words are present.
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 presence of an output schema (which documents return values), the description covers all essential aspects: purpose, usage context, input options, and output description. An agent has enough information 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 coverage is 100%, so baseline is 3. The description adds value by explaining that source_url supports TikTok, YouTube, or Instagram, and that transcript is a faster alternative. It also clarifies the relationship between the two required alternatives and the default behavior of my_topic.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Take a viral video and produce a fresh script that mirrors its structure and energy pattern for a new topic.' It specifies the verb (produce a script) and resource (viral video), and distinguishes from siblings like 'find_viral_template' by focusing on remixing a specific 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 explicitly tells when to use: 'Use when the user finds a video they want to replicate the structure of.' While it doesn't list alternatives or when not to use, the context is clear and sufficient for the agent to decide when this tool is appropriate.
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!