ugc-pocket
Server Details
Order UGC video campaigns from vetted creators. Drafts are confirmed and funded by a human.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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 7 of 7 tools scored. Lowest: 3.4/5.
Each tool targets a distinct resource or action: campaign status, order creation, brief estimation, service info, creator campaign listing, deliverable listing, and video submission. No two tools overlap in purpose; even 'list_my_campaigns' and 'list_my_deliverables' are clearly separated by resource type.
All tool names follow a consistent verb_noun pattern with snake_case (e.g., check_campaign_status, create_campaign_order). Conventions like 'list_my_' are uniform across similar tools, and there are no mixed styles or vague verbs.
With 7 tools, the server is well-scoped for a UGC campaign management API serving both brand-side (draft creation, estimation, status check) and creator-side (campaign viewing, deliverable management, video submission). Each tool earns its place without bloat or deficiency.
The tool set covers core workflows: brand creates drafts, estimates, checks status; creators view accepted campaigns, submit videos, monitor deliverables. Minor gaps exist, such as no brand-side campaign listing, update, or cancellation, and no creator-facing campaign browsing. However, the API intentionally offloads confirmation/funding to the app, so the surface is reasonably complete for its design.
Available Tools
7 toolscheck_campaign_statusCheck a campaign statusARead-onlyIdempotentInspect
Returns the status of a campaign (draft / open / in_progress / completed / cancelled). Scoped to campaigns belonging to the organization that owns the API key. Requires an API key.
| Name | Required | Description | Default |
|---|---|---|---|
| campaign_id | Yes | Campaign UUID returned by create_campaign_order. |
Output Schema
| Name | Required | Description |
|---|---|---|
| title | No | |
| status | No | |
| campaign_id | No | |
| confirm_url | No | |
| ordered_by_agent | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly and idempotent. The description adds context about scope and API key requirement, which is useful beyond annotations. 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?
The description is two sentences, no wasted words, and front-loaded with the main purpose. It is efficient and easy to parse.
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 an output schema, the description fully covers return values, scope, and requirements. 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 coverage is 100% and the description does not add new semantics beyond what the schema already provides (campaign_id from create_campaign_order). 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 the verb 'Returns' and the resource 'status of a campaign', listing all possible status values. It distinguishes from sibling tools (create_campaign_order, estimate_campaign, get_service_info) by being a read-only status check.
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 when to use (to check campaign status) and notes scope (organization) and requirement (API key). It does not explicitly exclude other tools, but the sibling differentiation is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_campaign_orderCreate a campaign order (draft)BInspect
Creates a UGC video campaign as a DRAFT (status='draft'). Nothing is charged: the brand owner must confirm and fund the campaign in the UGC Pocket app (the response includes a confirm_url to hand to them). Budgets are in euro cents: budget_max_cents is the spend cap for the WHOLE campaign, minimum 300000 (€3,000), and it is not necessarily spent in full (unspent budget is never charged). The number of creators is estimated from the cap, not chosen. Send an Idempotency-Key HTTP header to make retries safe. Requires an API key with the campaigns:draft scope.
| Name | Required | Description | Default |
|---|---|---|---|
| brief | Yes | ||
| title | Yes | ||
| deadline | No | ||
| platforms | No | ||
| objectives | No | ||
| prestation | No | ||
| payment_trigger | No | ||
| views_threshold | No | ||
| budget_max_cents | Yes | Maximum spend for the whole campaign, in euro cents. Minimum 300000 (€3,000), maximum 10000000 (€100,000). This is a cap: unspent budget is never charged. | |
| target_categories | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| status | No | |
| next_step | No | |
| campaign_id | No | |
| confirm_url | No | URL the human uses to confirm and fund the draft. |
| ordered_by_agent | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description claims idempotency support via header ('Send an Idempotency-Key HTTP header to make retries safe'), but annotations set idempotentHint=false, creating a contradiction. Score 1 per rules for 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 well-structured with key points front-loaded (draft status, no charge). It efficiently conveys important details without redundancy, though slightly verbose on budget explanation.
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 complexity (10 params, output schema exists), the description covers creation behavior, budget constraints, idempotency, and required scope. It omits error conditions and authentication details but is overall complete for a creation 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?
With schema coverage at 10%, the description adds some semantic value for budget_max_cents (euro cents, cap, minimum) but does not explain other 9 parameters like brief, deadline, platforms, etc. Insufficient compensation for low schema coverage.
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 creates a UGC video campaign as a draft. Verb 'creates' and resource 'campaign order' are explicit. It distinguishes from sibling tools like estimate_campaign by noting it's a draft and nothing is charged.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear when-to-use: creating a draft campaign. Includes context about confirmation and funding by brand owner, and that budgets are caps. However, does not explicitly mention when not to use or direct to alternative sibling tools like estimate_campaign for estimation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
estimate_campaignEstimate a campaign from a free-text briefARead-onlyInspect
Analyzes a free-text campaign brief (French or English) and returns structured campaign fields (title, prestation, categories, platforms, budget_max_cents) plus an estimate of what that cap can produce (creators briefed, videos, maximum tracked views). budget_max_cents is the spend cap for the WHOLE campaign, minimum 300000 (€3,000), and it is never necessarily spent in full. Writes nothing. Example brief: "I want UGC videos for our new kibble, dog owners, max budget €5,000". Requires an API key (ugcp_live_...).
| Name | Required | Description | Default |
|---|---|---|---|
| brief | Yes | Free-text campaign brief (French or English). |
Output Schema
| Name | Required | Description |
|---|---|---|
| estimate | No | What the suggested cap can produce: budget_max_cents, estimated_creators, estimated_videos (5 per creator), max_views (at €1 per 1,000 views). Null if no budget can be inferred. The cap is not an invoice: unspent budget is never charged. |
| suggested | No | Structured campaign fields inferred from the brief (including budget_max_cents). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors: it is read-only (consistent with readOnlyHint), requires an API key, enforces a minimum budget (300000 cents), and notes that the budget cap is never necessarily spent in full. These go beyond the annotation's readOnlyHint, adding actionable constraints for the agent.
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 well-structured and front-loaded with the core action. It includes essential details (output fields, budget constraint, example, API key requirement) without unnecessary verbosity. A slightly more compact structure could improve it, but it remains efficient.
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 simplicity (one parameter, output schema present) and high schema-description coverage, the description covers all necessary context: input format, output details, important budget rule, read-only nature, and authentication. No gaps are apparent.
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 single parameter 'brief' is fully described in the schema (100% coverage). The description adds value by specifying it expects free-text, in French or English, and provides an example. This clarifies semantic constraints 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 function: analyzing a free-text campaign brief (French or English) and returning structured campaign fields plus an estimate. It specifies the output fields (title, prestation, categories, platforms, budget_max_cents) and estimate components (creators briefed, videos, tracked views). The phrase 'Writes nothing' distinguishes it from siblings like create_campaign_order.
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 by stating it 'returns structured campaign fields plus an estimate' and 'Writes nothing', indicating it is a preliminary step before creation. However, it does not explicitly compare to alternative tools like create_campaign_order or provide when-not-to-use guidance. The example brief helps users understand typical input.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_service_infoGet service infoARead-onlyIdempotentInspect
Returns the UGC Pocket service descriptor: creator categories (e.g. dog, cooking, sport), prestation types, supported platforms, currency (EUR, budgets in cents), minimum campaign budget (300000 = €3,000, a spend cap for the whole campaign) and the order model (agent creates a draft, a human confirms and funds it in the app). No authentication required. Call this first to learn valid enum values.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| mcp | No | |
| docs | No | |
| name | No | |
| openapi | No | |
| currency | No | |
| platforms | No | |
| categories | No | |
| budget_unit | No | |
| description | No | |
| order_model | No | |
| prestations | No | |
| api_key_signup | No | |
| min_campaign_budget_cents | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds important behavioral details beyond annotations: no authentication required, explains currency and budget format (cents, min budget), and describes the order model.
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 sentences front-load the main purpose and efficiently pack all necessary details without 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?
Completely describes the tool's behavior, output, and usage context given there are no parameters and an output schema exists.
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, so schema coverage is 100%. The description adds value by explaining the output's content and structure, though it cannot add parameter-specific information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a service descriptor with specific components. It distinguishes itself from sibling tools that focus on campaigns or orders.
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 'Call this first to learn valid enum values,' providing clear when-to-use guidance and implying it should precede other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_my_campaignsList my campaigns (creator)ARead-onlyIdempotentInspect
For CREATOR API keys: lists the campaigns you are selected on (accepted application), with campaign_id, title, status, payment trigger and budget. Use the campaign_id with submit_posted_video to attach your published videos. Requires a creator API key (creator:submit scope) — generated in the UGC Pocket app under Settings.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| campaigns | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. Description adds value by stating the required API key type and scope, and that it only lists campaigns where application was accepted. 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?
Two efficient sentences. First sentence front-loaded with target audience and purpose, second provides actionable guidance. 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?
Given no input parameters and an output schema, the description covers purpose, usage, prerequisites, and downstream integration (attaching videos). Fully sufficient 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?
No parameters exist (input schema empty), so baseline score is 4. Description does not need to add parameter details; it already implies the tool returns all matched campaigns without filters.
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?
Clearly states it lists campaigns the user is selected on, for CREATOR API keys, and enumerates returned fields (campaign_id, title, status, payment trigger, budget). Distinguishes from siblings like 'check_campaign_status' and 'list_my_deliverables' by focusing on creator campaigns.
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 it is for CREATOR API keys, requires the 'creator:submit' scope, and directs using the campaign_id with 'submit_posted_video'. Provides clear when-to-use context and prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_my_deliverablesList my deliverables (creator)ARead-onlyIdempotentInspect
For CREATOR API keys: lists your submitted videos and their state (submitted / published / validated / revision / paid), tracked view counts and validated amounts in cents. Optionally filter by campaign_id. Requires a creator API key (creator:submit scope).
| Name | Required | Description | Default |
|---|---|---|---|
| before | No | Optional ISO timestamp: return deliverables created strictly before it (pagination — pass the oldest created_at of the previous page). Up to 200 per call. | |
| campaign_id | No | Optional campaign UUID to filter on. |
Output Schema
| Name | Required | Description |
|---|---|---|
| deliverables | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and idempotentHint, but the description adds value by detailing the returned data (state, view counts, validated amounts) and pagination behavior via the 'before' parameter, going 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?
Two sentences, front-loaded with the key audience restriction 'For CREATOR API keys', and every word adds value without 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?
With 2 optional parameters and an output schema (not shown but implied), the description covers the main response fields and pagination. It omits error handling or rate limits, but for a read-only list tool this is acceptable.
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 both parameters have descriptions, but the tool description adds essential context: 'before' is for pagination (pass oldest created_at of previous page, up to 200 per call) and campaign_id is optional. This clarifies usage 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 lists submitted videos with their state (submitted, published, etc.), tracked view counts, and validated amounts. It distinguishes itself from sibling tools like list_my_campaigns by explicitly focusing on deliverables and includes an optional filter by campaign_id.
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 specifies it is for CREATOR API keys and requires a creator:submit scope, providing clear context on when to use. It doesn't explicitly mention when not to use or alternatives, but the context is sufficient for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_posted_videoSubmit a posted video (creator)AIdempotentInspect
For CREATOR API keys: declare that you published a video on a social network for a campaign you are selected on. Give the public video URL (TikTok, Instagram or YouTube for automatic daily view tracking over 1 month; other https URLs are stored without tracking) and the campaign_id (see list_my_campaigns). Re-submitting the same URL for the same campaign is idempotent (returns the existing deliverable). Built for power users submitting many videos, e.g. hundreds for a challenge. Rate limit 30/min. Requires a creator API key (creator:submit scope).
| Name | Required | Description | Default |
|---|---|---|---|
| video_url | Yes | Public URL of the published video (https). | |
| campaign_id | Yes | Campaign UUID from list_my_campaigns. |
Output Schema
| Name | Required | Description |
|---|---|---|
| status | No | |
| campaign_id | No | |
| view_tracking | No | |
| deliverable_id | No | |
| already_submitted | No | true when this URL was already submitted for this campaign (idempotent replay). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses behavioral traits beyond annotations: idempotent (matches annotation), rate limit 30/min, requires creator API key with specific scope, and different handling for different URL types. 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?
Concise, front-loaded with purpose, no redundant sentences. Every sentence adds value: purpose, constraints, usage hints, and limitations.
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?
Complete for a 2-parameter tool with output schema. Covers purpose, usage guidelines, parameter details, idempotency, rate limits, auth requirements, and references sibling tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaning beyond input schema: explains video_url types (tracked vs stored) and campaign_id source (list_my_campaigns). Idempotency detail is also valuable. Schema coverage is 100% but description enriches both parameters.
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 is for creator API keys to declare publishing a video on a social network for a campaign, specifying verb (submit), resource (video), and distinguishing from siblings like check_campaign_status or create_campaign_order.
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: for CREATOR API keys, after publishing a video, with required scope. Provides context on URL types, idempotent re-submission, rate limit, and references list_my_campaigns for campaign_id.
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!