Trillboards Campaign Planner

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety and retry profile is covered. The description usefully adds that this feeds a moderation flow and that live artwork replacement is out of scope, but it never states whether attaching overwrites an existing draft asset, what permissions are required, or what the moderation outcome means for the caller.

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 short sentences with the core action front-loaded and no filler. The middle and third sentences carry the sequencing and exclusion information efficiently.

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?

An output schema exists so return values need not be described, and annotations cover the mutation/idempotency profile. Still, for a destructive attach operation with a nested required creativeFile object, the description leaves the post-attach state and moderation consequences unexplained.

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 67% and the description mentions no parameter at all — no hint about advertisementId coming from save_campaign_draft, no explanation of how creativeFile's file_id/download_url are used, and no mention of the idempotency_key despite it being required. It adds essentially nothing beyond the schema 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?

The description names a specific verb+resource ('Copy a user-selected creative file into the native campaign asset and moderation flow'), so an agent knows exactly what is being moved and where. It does not name any sibling tool, but the operation is distinct enough from create_campaign_checkout or save_campaign_draft to be identifiable.

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?

'Attach artwork before booking' gives an explicit timing condition for use, and 'Existing live artwork changes follow the portal replacement workflow' tells the agent when this tool is the wrong path. No sibling is named directly, but the when/when-not split is present.

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 openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that: the returned checkoutUrl must be opened to complete payment, and the campaign is only booked after a verified native Stripe payment webhook — a deferred, asynchronous completion the annotations cannot express.

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 short sentences, zero filler, and the core action is front-loaded before the post-conditions. Every sentence contributes distinct information (what it creates, what to do with the output, when the booking lands).

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?

An output schema exists, so return-value fields like checkoutUrl need not be re-explained. For a mutating, open-world tool with a nested-object schema and 50% coverage, the description captures the payment-flow lifecycle well, though it leaves several optional parameters (quoteIds, bookingIds, providerLineIds) unexplained.

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 50% (10 params, 6 required), so the description carries partial burden. It reinforces that the submitted values must be the exact campaign and total the buyer reviewed, matching the reviewed* fields, but adds no meaning for the undocumented quoteId, quoteIds, bookingIds, providerLineIds, or reviewedSubtotalUsd 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?

States a specific verb+resource ("Create a Stripe checkout") scoped to the exact campaign and reviewed total, which separates it from the drafting/preparation siblings in the schema chain (save_campaign_draft, prepare_campaign_booking). It does not name a sibling tool directly, so differentiation is inferential rather than explicit.

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 is implied through the payment lifecycle (open checkoutUrl, booking completes on Stripe webhook), which tells the agent this is the terminal step after preparation. However, there is no explicit statement of when to use this versus prepare_campaign_booking or preview_campaign_plan, and no exclusions or prerequisites named.

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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds the useful detail that data comes from the native campaign reporting services, but says nothing about freshness, pagination, or result limits, so it adds only modest value beyond the structured fields.

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?

A single front-loaded sentence that describes the tool without filler or repetition of the name. It is efficient, though the phrase 'native campaign reporting services' is slightly opaque for the space it consumes.

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?

An output schema exists, so return values need not be described, and the annotations cover safety. However, for a paginated reporting read the description omits the limit/pagination semantics and the array of closely named siblings, leaving real 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 description coverage is 50%: advertisementId is documented (including its link to save_campaign_draft) but 'limit' is undocumented in the schema. The description mentions no parameters at all, so it neither explains the limit/pagination behavior nor the ID requirement, leaving half the parameter surface unexplained.

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?

Clear verb ('Read') plus a specific resource ('measured campaign delivery and screen performance'), which an agent can distinguish from status-check siblings like get_campaign_status. It does not explicitly name which sibling to prefer, so it stops short of a 5.

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 states what is retrieved but gives no when-to-use condition, no prerequisites (e.g., a campaign must already exist), and no alternatives such as get_campaign_status. Usage must be inferred entirely from the name.

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 annotations already declare this as a read-only, idempotent, non-destructive operation, so the safety profile is covered. The description adds useful context by specifying the data source ('same order records as the advertiser portal') and the included status areas, but it does not disclose auth requirements, rate limits, or caveats about freshness.

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 immediately states the action and resource, then adds the most relevant scope details. There is no redundant or filler text.

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 low complexity (one required parameter), the presence of an output schema, and annotations that cover safety semantics, the description provides enough context about what is read and where it comes from. The main missing piece is routing guidance versus sibling tools such as get_campaign_delivery, which is a usage-guideline gap rather than a completeness 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 description coverage is 100%, and the single required advertisementId parameter is fully documented in the schema as a native campaign ID returned by save_campaign_draft. The description adds no additional parameter semantics, so the baseline of 3 is appropriate when the schema already does the heavy lifting.

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 ('Read') and resource ('campaign and booking progress'), and then names concrete included areas (creative review, scheduled dates, live fulfillment). It clearly states what the tool does, but it does not explicitly distinguish itself from the sibling get_campaign_delivery, where the word 'fulfillment' could cause overlap.

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 does not say when to use this tool, when not to use it, or which sibling to choose instead. The only implicit guidance comes from the input schema noting that advertisementId is returned by save_campaign_draft, but that is not surfaced in the description itself.

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=true, idempotentHint=true and destructiveHint=false, so the safety profile is fully covered and the description's 'Read' is consistent. The description adds only modest workflow context (a review/preparation step) and nothing on auth, limits, or empty-quote 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?

A single front-loaded sentence that packs the returned fields coherently with zero filler. Nothing could be cut without losing 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?

Because an output schema exists, the description need not explain return values, and annotations carry the safety profile. However, with a nested quoteIds object and four undocumented parameters, an agent is left to guess at how quoteIds/bookingIds/providerLineIds shape the 'selections' being read.

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?

Five parameters with only 20% schema description coverage (only advertisementId is documented). The description mentions none of quoteId, quoteIds, bookingIds or providerLineIds, so it fails to compensate for the four undocumented inputs.

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?

States a specific verb ('Read') and enumerates the resources returned: selections, total, currency, creative readiness. The phrase 'before payment' implicitly distinguishes it from the sibling create_campaign_checkout, though it never names the alternative directly.

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?

'...for the buyer to review before payment' implies the usage context (the pre-payment review step), but there is no explicit when-to-use/when-not guidance and no sibling named. Usage is inferable rather than stated.

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=true, idempotentHint=true and destructiveHint=false, so the agent knows this is a safe, repeatable read. The description restates the side-effect-free nature in business terms (no inventory reservation, no charge), which adds domain-specific clarity but little beyond the annotations; no auth, latency, or rate-limit context is provided.

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 tight sentences with no filler; the positive scope is front-loaded and the side-effect disclaimer follows immediately. Every clause earns its place.

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?

An output schema exists so return values need not be described, but for a 20-parameter tool with only 2 required fields and a complex nested providerPlan branch, the description omits critical guidance on which parameter combinations to supply. The gap between the schema's complexity and the description's size is large.

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 20% across 20 parameters, and the description compensates with nothing beyond naming 'screens and channels.' It does not explain the flat-vs-providerPlan budget/impression variants (budgetUsd vs ownedBudgetUsd vs partnerBudgetUsd), quoteId vs quoteIds, the source enum, or the deeply nested targeting/geography objects.

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?

States a specific verb (preview) and resource (campaign plan) and specifies the outputs: pricing and audience estimates for selected screens and channels. It implicitly distinguishes itself from booking/checkout siblings by clarifying it does not reserve inventory or charge, though it does not name those siblings explicitly.

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 'does not reserve inventory or charge' clause implies this is the pre-booking estimate step (before prepare_campaign_booking / create_campaign_checkout), but usage is left to inference. No explicit when-to-use statement or named alternative tool is given.

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 idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds real business context beyond that: the result is an *unpaid* campaign, creative lineage is preserved, prices are re-fetched, and a new review plus payment is required before it goes live.

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 tight sentences with no filler. The core action and its outcome are front-loaded, and the prerequisite (review and payment) is placed last as a caveat rather than padding.

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?

An output schema exists, so return values need not be described. The description covers what is created, what is carried over, and the review/payment gate — sufficient for a 4-parameter mutation. It could go slightly further on the relationship to the source campaign's state after rebooking.

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%, with each of the four parameters documented in the schema itself (including the idempotency_key retry semantics). The description adds no parameter-level detail such as date-range constraints or the relationship between advertisementId and the copied campaign, so the baseline 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 gives a specific verb and resource ('copy a previous campaign into a new unpaid campaign for new dates') plus the key outcome (native creative lineage preserved, fresh prices obtained). It is clearly distinguishable from siblings like save_campaign_draft or prepare_campaign_booking, though it never names an alternative explicitly.

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 scenario is implied — use this to rerun a past campaign on new dates — and the line 'Rebooking requires a new review and payment' hints at a prerequisite. However, there is no explicit when-to-use versus when-not guidance, and no sibling is named as an alternative for adjacent tasks.

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 destructiveHint=true and idempotentHint=true, so the description should explain what gets overwritten on an existing draft and how the idempotency_key retry works. Instead it only adds the ownership/payer business semantics ('agency remains the owner and payer'), never addressing the destructive upsert behavior the annotations flag.

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 tight sentences with no filler, and the primary action is front-loaded ahead of the secondary ownership/labeling caveat. Nothing is wasted for the space it occupies.

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 21-parameter tool with nested objects, an enum, and a providerPlan union, the description is far too thin – it never addresses the owned vs partner vs mixed source model or the budget/impression split. The presence of an output schema excuses it from explaining return values, but the input complexity is unaddressed.

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 24% across 21 parameters, so the description must carry the load and does not. It clarifies clientName (labels the client brief) but says nothing about source, quoteId vs quoteIds, budgetUsd vs ownedBudgetUsd/partnerBudgetUsd, or the complex providerPlan object.

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?

States a specific verb pair (save/update) and resource (agency-owned campaign plus selected inventory) with a clear upsert intent. It does not differentiate from siblings like create_campaign_checkout or prepare_campaign_booking, so the agent must infer which one persists a draft versus initiates booking.

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?

There is no when-to-use guidance and no mention of alternatives among the eight sibling tools. The agent is left to guess whether this is the correct call before checkout/booking or what precondition (e.g., an existing quoteId) is required.

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=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safe-read profile is covered. The description only adds that it reads from the advertiser portal inventory and prices; it says nothing about pagination behavior or result scope beyond what the schema and output schema imply.

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 tight sentences with the purpose front-loaded and no filler. It is efficient, though it could trade a few words for missing usage or parameter 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?

An output schema exists, so return values need not be explained, and annotations carry the safety profile. However, with 8 parameters, a nested radius object, and 38% schema coverage, the description is thin on how to filter (city vs radius, source, paging) for a tool whose whole job is querying inventory.

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 38%, leaving limit, state, cursor, source, and channels undocumented in the schema. The description's mention of product categories loosely maps to the channels enum, but it does not explain the source enum, cursor paging, or how city/state/query/radius interact, so it does not compensate for the coverage gap.

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?

States a specific verb (Find) and concrete resources (digital out-of-home screens; CTV, video, audio, display products), which an agent can distinguish from the sibling campaign lifecycle tools. It stops short of explicitly naming an alternative, so it is clear but not sibling-differentiating at the top level.

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 notes the audience ('for an agency client') and the data source ('advertiser portal inventory and prices'), but gives no guidance on when to use this search versus preview_campaign_plan, prepare_campaign_booking, or other siblings. No prerequisites or exclusions are stated.

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