Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ugc-brief-mcp Check this brief for red flags and scope creep"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
The production layer for UGC creators. Turn a brand brief into deliverables, shot lists, and the right format, and catch the traps before you shoot.
Disclaimer. Structured UGC-production frameworks from documented creator practice. Confirm deliverables, usage, and revisions in writing before shooting. This server plans the work; it never sets or quotes rates.
You landed the deal. Now what do you actually shoot? Most creators (and their AI assistants) jump straight to filming and end up with the wrong format, undefined deliverables, and a "quick revision" that becomes ten. This MCP reads the brief like a pro: what you deliver, in what format, to what spec, and where the scope traps are.
Related MCP server: Growth Hacker MCP
Tool | What it returns |
| Detected deliverables/specs/usage/disclosure + red flags + the exact questions to confirm in writing |
| The 10 fields every brief must answer before you shoot |
| The 7 UGC ad formats (testimonial, problem/solution, unboxing, demo, GRWM, comparison, hook-test-pack) with structure |
| A beat-by-beat shot list for a format + coverage rules (shoot the hook 3 ways) |
| The fields to lock so nothing is left open to interpretation, plus a confirm-message shape |
| Scan for unlimited revisions, perpetual usage, spec work, raw-file grabs, vague deliverables, scope creep |
| Everything in one payload |
npx ugc-brief-mcp{ "mcpServers": { "ugc-brief": { "command": "npx", "args": ["ugc-brief-mcp"] } } }Land it (outbound-engine-mcp) → price it (creator-deals-mcp) → produce it (this one) → repurpose it (content-repurposing-mcp). Full catalog: MCP Hub
Elisabeth Hitz — 10+ years enterprise sales, reverse-engineered for creators.
License: MIT
Given a UGC format, returns a beat-by-beat shot list template with coverage rules (shoot the hook 3 ways, get product close-up + in-use wide + reaction). Formats: testimonial, problem_solution, unboxing, demo_tutorial, get_ready_with_me, comparison, hook_test_pack.
| Name | Required | Description | Default |
|---|---|---|---|
| format | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses that the tool generates a template with coverage rules, and gives examples of rules. No destructive behavior is implied, and the description is transparent enough for a read-only 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 a single sentence plus a list of formats, perfectly concise and front-loaded with the key action. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is complete: it explains input and output (returns a shot list template). Minor omission: no detail on output format, but acceptable given simplicity.
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 0%, so description must add meaning to the parameter. The description lists the enum values again and explains that the parameter is the UGC format, adding value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: given a UGC format, it returns a beat-by-beat shot list template with coverage rules. The list of supported formats distinguishes it from siblings like get_ugc_formats, which likely only lists formats.
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 implies usage when a shot list template is needed for a specific UGC format. However, it does not explicitly contrast with sibling tools or provide when-not-to-use guidance, which would make it clearer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan a brief or message for production/scope red flags: unlimited revisions, perpetual usage, spec-first requests, raw-file grabs, vague deliverables, post-agreement scope creep. Returns flags + what to do.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full behavioral disclosure. It states the tool returns flags and advice, and the verb 'scan' suggests read-only behavior. However, it could be more explicit about side effects or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the tool's purpose and output. It is front-loaded with the action, though the list of red flags could be shortened without losing clarity.
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 one parameter, no output schema, and no annotations, the description adequately describes input and output (flags + advice). However, it lacks details on return format, which could be helpful for a complete picture.
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 0%, so the description must compensate. It adds the context that the text is 'a brief or message' but provides no additional meaning about length, format, or constraints beyond the schema's type.
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 scans a brief or message for specific production/scope red flags, listing examples. The verb 'scan' and resource 'brief or message' are specific, and it distinguishes itself from siblings like build_shot_list or get_brief_checklist.
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 implies usage (when to scan for red flags) but provides no explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The 10-point checklist every UGC brief must answer before you shoot: deliverables, usage, exclusivity, revisions, raw-vs-edited, specs, hooks, talking points, timeline, brand assets.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description indicates a read-like operation but does not disclose side effects, return format, or any behavioral constraints. For a tool with no annotations, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a clear list, front-loading the key information. Every part adds value with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lists the checklist categories but does not specify the output format or structure. Without an output schema, the agent lacks details on what the returned data looks like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is no need for additional parameter explanation. The description implicitly covers the tool's purpose without requiring parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a 10-point checklist for UGC briefs, listing specific categories. It distinguishes from sibling tools like 'build_shot_list' and 'check_brief_red_flags' by focusing on overall brief completeness.
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 phrase 'every UGC brief must answer before you shoot' implies usage before shooting, but there is no explicit guidance on when not to use this tool or alternatives. No exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The complete UGC-brief library in one payload: formats, brief checklist, red flags. For full agent context.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose potential side effects, authentication needs, rate limits, or payload size, leaving behavioral traits unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-loaded with purpose; no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema; description lists contents but does not specify return structure, formatting, or how data is organized, leaving context incomplete for agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; schema coverage is 100% (empty), so description does not need to add parameter details, matching the baseline of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it provides the complete UGC-brief library including formats, brief checklist, and red flags, distinguishing it from sibling tools that offer subsets.
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?
Implies use for full agent context but does not explicitly state when to prefer this over siblings or mention any exclusions or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The core UGC ad formats with structure and when to use each: testimonial, problem_solution, unboxing, demo_tutorial, get_ready_with_me, comparison, hook_test_pack. Omit format for all.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only mentions what the tool returns, not behavioral traits like side effects, permissions, or rate limits. The tool is a getter but this is not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the tool's purpose, lists all options, and includes a usage tip without any unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one parameter and no output schema, the description adequately covers purpose, parameter behavior, and expected output structure, though it could elaborate on the return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to the format parameter by explaining that omitting it returns all formats, which is not in the schema (schema coverage 0%). This is valuable context.
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 UGC ad formats with structure and usage guidance for each format, distinguishing it from sibling tools like build_shot_list or interpret_brief.
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 implies usage (get format info, omit for all) but does not explicitly state when to use this tool versus siblings or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Paste a brand's UGC brief. Returns detected deliverables/specs/usage/disclosure, red flags (unlimited revisions, perpetual usage, spec work, raw-file grabs), and the exact questions to confirm in writing before agreeing.
| Name | Required | Description | Default |
|---|---|---|---|
| brief | Yes | The full brand brief text |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. States it returns analysis but does not disclose idempotency, authorization, or side effects. Since it likely only processes the input, a 3 is adequate but could say 'no data stored'.
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 sentence, front-loaded with action verb 'Paste', lists outputs clearly. No wasted words, efficient and structured.
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 simple input and no output schema, description details outputs (deliverables, red flags, questions). Could mention return format (e.g., text list vs JSON) for completeness, but sufficient overall.
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?
Only one parameter 'brief' with 100% schema coverage. Description adds context that it's a brand's UGC brief, clarifying the type of text beyond the schema's 'full brand brief text'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool interprets a brand's UGC brief and returns specific outputs (deliverables, red flags, questions). Distinguishes from siblings like check_brief_red_flags by covering full analysis beyond just red flags.
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?
Clearly implies use when you have a UGC brief to analyze. However, does not explicitly state when not to use or mention sibling alternatives like check_brief_red_flags for simpler needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turn a vague ask into a defined deliverable list. Returns the exact fields to lock (count, format, length, aspect, revisions, raw-vs-edited, usage window) so nothing is left open to interpretation.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains the output (defined list with fields) but does not disclose side effects, idempotency, or whether it mutates state. Given no parameters, the behavior is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the purpose and key output fields without any wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no input parameters and no output schema, the description provides sufficient information: it lists the exact fields returned. It could clarify how the 'vague ask' is sourced, but overall it is adequate for a simple tool with zero parameters.
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 tool has no parameters, so the description cannot add meaning beyond the input schema. With zero parameters, a baseline score of 4 is appropriate; no extra parameter documentation is needed.
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 function: converting a vague ask into a defined deliverable list. It enumerates specific fields returned (count, format, etc.), distinguishing it from sibling tools like build_shot_list or check_brief_red_flags.
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 implies usage when a vague ask needs refinement, but it does not explicitly differentiate from siblings or state when not to use the tool. Guidance is minimal but not absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0build_shot_listcheck_brief_red_flagsget_brief_checklistget_full_packget_ugc_formatsinterpret_briefscope_deliverablesScored across 7 tools
Most tools have distinct purposes, but 'interpret_brief' and 'check_brief_red_flags' both deal with red flags, which could cause confusion. Descriptions help differentiate, with 'interpret_brief' being more comprehensive.
Naming follows a mostly consistent verb_noun pattern (e.g., get_ugc_formats, build_shot_list). Minor deviations like 'get_full_pack' (uses 'full' instead of a noun like 'library') are still clear.
Seven tools cover the UGC brief domain well without being excessive. Each tool has a clear role, from analyzing briefs to generating shot lists and scoping deliverables.
The tool set covers core UGC brief analysis and preparation tasks. Missing are tools for creating or editing briefs, but the given purpose (assisting with existing briefs) is well-served.
Create, manage, schedule, and publish short-form user-generated content through AI agents.
Create AI UGC content, generate/clone media, clip video, and publish to social accounts.
Virality detection for creator agencies: find viral posts, AI breakdowns, creator briefs.
Promote your app or software with UGC creator videos. Agent drafts the campaign, a human funds it.
