ugc-pocket

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare the tool read-only and idempotent, so the description adds value by disclosing the API key requirement and organizational scoping. These are non-obvious behavioral constraints not covered by 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 two sentences with the core functionality front-loaded and no extraneous information. Every clause adds value, making it highly concise and well-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?

For a simple read-only status tool with one well-documented parameter and an output schema (not shown but present), the description covers the essential contextual aspects: return value, scope, and auth. No significant gaps exist.

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 schema fully documents the only parameter (campaign_id) as a UUID from create_campaign_order, providing 100% coverage. The description adds no further parameter detail, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns a campaign's status with an explicit enumeration of possible values, using a specific verb-resource pair. This distinguishes it from sibling tools like list_my_campaigns, which list campaigns rather than check a single campaign's status.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context by noting the organizational scope and API key requirement, implying this tool is for checking own-org campaigns. It doesn't explicitly name alternatives or exclusions, but the context is sufficient for an agent to infer appropriate usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description goes well beyond the annotations (all false) by disclosing key behaviors: no API key/account needed, nothing charged, nothing published to creators, draft expires in 7 days, user logs in with a 6-digit email code, and returns a claim_url. This gives the agent a clear mental model of side effects and lifecycle.

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 critical 'START HERE' signal and is dense with high-value information. Every sentence carries purpose—usage, workflow, safety, expiry, budget constraint, and tool preference—without fluff or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's 16 parameters and complex no-account flow, the description covers the full context: why to use it, what to fill, what happens after creation, claim_url behavior, expiration, billing, and the alternative tool. The output schema exists and can handle return-value details, so the description is sufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With only 44% schema coverage, the description adds meaningful semantics for budget_max_cents (campaign package, minimum €2,000, invoiced in full), the company object (shown on claim page, pre-fills profile), and email (receives campaign by mail). It also suggests which fields to fill from user/website. However, it doesn't cover all 16 params (e.g., min_views, payment_trigger, deadline), though many have 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 opens with 'START HERE' and states a specific verb+resource: 'Builds a complete UGC campaign draft' without an account. It also clearly distinguishes itself from siblings by saying 'Prefer this tool over create_campaign_order unless the user already has a ugcp_live_ key configured,' making the tool's unique role unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage guidance is explicit and actionable: 'START HERE when a user asks how to promote their app, software, service or course,' plus direct comparison to the alternative tool. It also provides workflow context ('Do the work first and ask for an account later') and instructs the agent to fill in fields from user input and the website.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses many behaviors beyond the annotations: draft status, no charge until confirmation, confirm_url, full invoicing, budget in cents, creator pay handling, idempotency header, and required scope. Since annotations are all false, there is no contradiction and the description carries the full burden well.

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 front-loaded, with each sentence adding valuable information about the draft flow, payment model, idempotency, and prerequisites. No fluff or unnecessary repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (14 params), the description provides a solid overview of the campaign creation process, payment semantics, and required scope. The output schema presumably covers return values. However, it could have elaborated on ambiguous parameters, but it is still sufficiently complete for an agent to use 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 only 36%, so the description must compensate. It adds context about budget_max_cents as a package and explains that creator pay is not set by the brand, but many parameters (deadline, platforms, objectives, payment_trigger, views_threshold, target_categories) remain without meaningful descriptions. The description partially compensates but does not fully cover the gaps.

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 with status='draft', and explains the confirmation/funding flow. This distinguishes it from siblings like create_campaign_draft by emphasizing the draft status and the confirm_url handoff.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explains the workflow: the brand owner must confirm and fund in the UGC Pocket app, and it mentions the required API scope (campaigns:draft). It does not explicitly name alternative tools, but the context is clear enough for the agent to decide when to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnlyHint annotation, the description adds non-obvious behavioral details: it refuses to return projections ('those ratios change constantly...'), defines budget constraints ('minimum 200000, invoiced in full'), and notes the API key requirement. No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is four sentences, front-loaded with the main purpose, and every sentence adds essential context: the exact output fields, the intentional omission of projections, the budget rule, the example, and the auth requirement. No 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?

For a one-parameter read-only tool with an output schema, the description covers all necessary operational knowledge: input language support, output fields, special behavioral constraints, example input, and authentication. Sibling context and annotations round out the 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?

The schema already describes the single parameter 'brief' with 100% coverage, so the baseline is 3. The description adds a concrete example and restates language support, but this is marginal over the schema description.

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 states a specific action ('Structures a free-text campaign brief...') with a clear resource and scope. It distinguishes itself from sibling tools by explicitly saying 'Writes nothing' and 'Returns NO projection of views...', separating it from creation or status-checking tools.

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 gives clear context: use when you have a free-text brief in French or English and want structured campaign fields. It implicitly differentiates from create/order tools via 'Writes nothing', but does not explicitly name alternatives or exclusions, so it stops short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and idempotentHint true, and the description adds 'No authentication required,' a useful behavioral detail not captured by annotations. It also describes the order model context, but without more depth on potential side effects (though none apply here).

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 efficient: a single structured sentence listing key contents, followed by two short sentences on authentication and usage. It is front-loaded with the main verb and resource, and every clause 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?

Given the tool's simplicity (no inputs) and the presence of an output schema, the description is remarkably complete. It covers what data is returned, the order model, onboarding steps, and when to call it, leaving no gaps for the 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?

The tool has zero parameters, so the schema provides no parameter descriptions. Per the rubric, 0 params earns a baseline of 4. The description focuses on output details rather than parameters, which 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 tool's purpose: 'Returns the UGC Pocket service descriptor' and enumerates specific contents like creator categories, platforms, currency, budgets, order model, and onboarding steps. It distinguishes from sibling tools by framing itself as the first call for enum values and account setup.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit usage guidance: 'Call this first to learn valid enum values, or whenever you need to tell a user how to connect UGC Pocket to their agent.' This tells the agent exactly when to invoke it, and implicitly contrasts with sibling campaign-related tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds valuable context beyond the annotations by detailing the required creator API key scope (creator:submit), the filter of accepted applications, and the output fields. This complements the readOnlyHint and idempotentHint 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 concise, consisting of three short sentences that are front-loaded with the purpose. Every sentence provides essential information 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?

For a tool with no parameters and an output schema, the description fully covers the purpose, the creator-only scope, authentication requirements, and the follow-up action with submit_posted_video. It is complete and self-sufficient.

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 the baseline is 4. The description does not need to explain parameters, and it correctly does not attempt to. It does mention output fields, but that is not parameter semantics.

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 the campaigns the creator is selected on (accepted applications), with specific fields returned. This distinguishes it from sibling tools like check_campaign_status and list_my_deliverables.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It specifies the tool is for CREATOR API keys and explains how to use the resulting campaign_id with submit_posted_video. However, it does not explicitly mention alternatives or when not to use the tool, so it stops short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is known. The description adds valuable context: auth requirement (creator:submit scope), the specific data returned (states, view counts, amounts in cents), and that it only lists the caller's own videos. 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 two sentences, front-loaded with the intended audience ('For CREATOR API keys'), and every sentence contributes essential information (what is listed, states, auth requirement). 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 listing tool with only two optional parameters and an output schema, the description is complete. It covers the purpose, data returned, auth, and filtering. Return values are handled by the output schema, so no need to elaborate further.

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 ('before' and 'campaign_id') have descriptive comments in the schema. The description only mentions 'Optionally filter by campaign_id' without adding new meaning beyond what the schema already provides, so the baseline score 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 tool lists 'your submitted videos' with specific state values (submitted/published/validated/revision/paid), view counts, and validated amounts in cents. It uses the specific verb 'lists' and identifies the resource (deliverables), distinguishing it from the sibling 'list_my_campaigns' which lists 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?

The description provides clear context by stating 'For CREATOR API keys' and mentions the required scope (creator:submit), which indicates who should use it. However, it does not explicitly exclude alternatives or state when not to use it, so it falls short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the idempotentHint annotation, the description details idempotency behavior (returns existing deliverable), rate limits (30/min), authentication scope (creator:submit), and tracking behavior for different URL types. This fully discloses the tool's operational characteristics and constraints.

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 dense but every sentence carries essential information: purpose, parameter guidance, idempotency, intended audience, rate limit, and auth requirement. There is no filler or redundancy, and the most important information (purpose) is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter tool, the description covers all critical aspects: purpose, parameter semantics, behavioral details, rate limiting, and authentication. An output schema exists, so return values need not be described. This is a fully self-contained description for an agent to select and use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds significant value by explaining the video_url parameter's tracking implications (automatic daily tracking for certain platforms, storage without tracking for others) and by pointing to list_my_campaigns for campaign_id. This goes beyond the schema's simple field 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's purpose: for CREATOR API keys to declare publication of a video for a selected campaign. It specifies the action (submit/declare), the resource (posted video URL), and the scope (campaign), distinguishing it from sibling tools like list_my_campaigns 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?

The description provides clear context: it is for creator keys, campaigns you are selected on, and explains that campaign_id comes from list_my_campaigns. It also notes the difference between trackable URLs (TikTok/Instagram/YouTube) and others. However, it does not explicitly say when NOT to use this tool or name alternative tools, so it stops short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.