ugc-pocket

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.

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

The description fully discloses behavioral traits: creates a draft (status='draft'), no charge occurs, requires idempotency key for safe retries, requires specific API scope, and budget constraints in euro cents. Annotations provide no hints (all false), so description carries full burden and does so comprehensively. 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 a single, moderately dense paragraph. It is concise but could be more structured (e.g., bullet points for constraints). Every sentence adds value, no filler. Slightly above average.

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 11 parameters and 0% schema coverage, the description covers the core workflow (draft, no charge, confirmation URL) but leaves many parameters unexplained. Output schema likely covers return shape, so that's fine. However, for a tool with this complexity and parameter count, more parameter guidance would improve completeness.

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 description must explain parameters. It covers budget_per_creator_cents (min/max, currency unit) and creators_wanted (range). title and brief are implied as required but not explained. Other optional parameters (deadline, platforms, objectives, etc.) are not mentioned. While it adds value for key params, complete parameter explanation is lacking.

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 creates a UGC video campaign as a draft (status='draft'). The verb 'creates' and resource 'campaign order (draft)' are specific. It distinguishes from siblings: check_campaign_status (read), estimate_campaign (estimate), get_service_info (info). No ambiguity.

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 explains when to use: for creating a draft campaign order, with note that nothing is charged and brand owner must confirm via confirm_url. It mentions idempotency key and required API scope. However, it does not explicitly state when not to use or compare directly with siblings, though context from sibling names helps. Still clear enough.

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 declare readOnlyHint=true, and the description reinforces with 'Writes nothing'. It adds context about the API key requirement and example, but does not discuss idempotency or rate limits beyond what annotations hint (idempotentHint=false).

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 plus an example and a note, highly concise and front-loaded with the action. Every sentence adds value: purpose, output, behavior, and requirements.

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 simple single-parameter tool and presence of an output schema, the description covers necessary context: input, output fields, behavior, language support, and example. No gaps for correct invocation.

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 a single brief parameter. The description adds value by providing an example brief and clarifying language support (French/English), which aids in parameter formatting beyond 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 clearly states the verb 'Analyzes' and the resource 'a free-text campaign brief'. It specifies the tool returns structured campaign fields and writes nothing, distinguishing it from sibling tools like create_campaign_order. Language support (French or English) adds specificity.

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 for analyzing a brief to get an estimate but does not explicitly state when to use or when not to use this tool versus alternatives. No exclusions or alternative suggestions are provided beyond the API key requirement.

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 indicate readOnly and idempotent; description adds 'No authentication required' and details the returned information (currency, budget representation, order model), going beyond annotations to fully disclose behavior.

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 states main purpose, second provides key details. Every phrase earns its place; 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?

Given no parameters and an output schema present, the description sufficiently explains return values, including interpretation of budget fields and the order model, making it complete for a service info 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?

No parameters; baseline is 4. Description adds meaning about output context (e.g., minimum budget 5000 = €50) but since no parameters exist, it cannot add 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?

Description clearly states it returns the UGC Pocket service descriptor with specific fields (creator categories, prestation types, etc.), distinguishing it from sibling tools like check_campaign_status or create_campaign_order which are not discovery 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?

Explicitly instructs 'Call this first to learn valid enum values,' providing clear when-to-use guidance and implying it is a prerequisite for other tools that require valid enums.

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