Trillboards Campaign Planner

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

Annotations already declare destructiveHint=true, idempotentHint=true, and openWorldHint=true, so the bar is lower. The description adds useful context about the moderation flow and points existing-live-artwork changes to a separate portal workflow, but it never discloses what this call destroys or overwrites, and the 'existing artwork → portal' line arguably undersells the destructiveHint. Idempotency is covered only by the schema's idempotency_key field, not the prose.

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, followed by timing and the alternative workflow. No filler, though the middle sentence could be merged and the jargon slightly reduces scannability.

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 much of the safety profile. However, for a destructive, open-world mutation with a nested file object, the description omits permissions/auth needs, what moderation entails, and what happens to prior artwork, leaving real 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 description coverage is 67%, so the schema already documents advertisementId and idempotency_key. The description adds nothing about parameters and leaves the nested creativeFile object's four sub-properties (file_id, file_name, mime_type, download_url) undescribed in both places, which is a gap for a nested input. Baseline 3 is appropriate given partial 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 states a specific verb and resource: 'Copy a user-selected creative file into the native campaign asset and moderation flow.' This distinguishes it from sibling read/booking tools like get_campaign_status or prepare_campaign_booking, though the phrase 'native campaign asset and moderation flow' is jargon that a first-time agent must interpret.

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 gives clear timing guidance ('Attach artwork before booking') and routes a specific case away ('Existing live artwork changes follow the portal replacement workflow'). It stops short of naming a sibling tool or stating prerequisites (e.g., campaign must exist in draft), so it is strong context but not fully explicit when/when-not routing.

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 the mutation/idempotent/open-world profile, and the description adds real behavioral context beyond them: the buyer must open the returned checkoutUrl, and the campaign is only booked after a verified native Stripe payment webhook (i.e., completion is asynchronous and not guaranteed by the call itself). It does not mention rate limits or what happens if the checkout expires.

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, front-loaded with the action and scoping constraint, then the next step, then the completion condition. Every sentence earns its place with no filler.

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 10-parameter write tool with an output schema and full annotations, the description covers the essential flow an agent needs: what is created, that the checkoutUrl must be opened, and that booking is confirmed only via webhook. Return-value detail is delegated to the output schema, so nothing critical is missing.

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 50%, so the schema documents reviewedAmount, advertisementId, idempotency_key, reviewedCurrency and reviewedSelection but leaves quoteId, quoteIds, bookingIds, providerLineIds and reviewedSubtotalUsd unexplained. The description reinforces that the reviewed* fields must match the reviewed quote, but adds no syntax or meaning for the five undocumented 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 and resource (create a Stripe checkout for a campaign) and scopes it precisely to the 'exact campaign and total the buyer reviewed', which implicitly separates it from prepare_campaign_booking. It never names a sibling tool outright, so an agent must infer the ordering from the word 'reviewed'.

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

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

The phrase 'the exact campaign and total the buyer reviewed' implies this must be called after prepare_campaign_booking with matching reviewed values, and 'Open the returned checkoutUrl' implies the post-call step. However, there is no explicit when-to-use/when-not guidance and no named alternative, leaving the prerequisite chain to inference.

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 by structured data. The description adds only that data comes from 'native campaign reporting services' and is 'measured', implying aggregated/reported rather than real-time values, but says nothing about freshness, pagination behavior, or result volume.

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 with no filler or repetition. It is efficient, though so terse that it borders on under-specification for a tool with an undocumented pagination parameter.

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 the read-only annotations cover the safety story. What is missing is the disambiguation from get_campaign_status and any statement about pagination or data freshness, leaving the agent with gaps for a tool that overlaps a sibling.

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 in the schema (including the pointer to save_campaign_draft), but limit is undocumented in both schema and description. The description adds no parameter-level meaning at all, though the required parameter is already well covered by the schema, making 3 the appropriate baseline.

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 — 'Read measured campaign delivery and screen performance' — so an agent knows this returns performance measurement data, not campaign configuration. It does not, however, distinguish itself from the sibling get_campaign_status, which sounds like an overlapping read of campaign state.

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, no prerequisites, and no mention of the sibling get_campaign_status as an alternative. The phrase 'from the native campaign reporting services' hints at a data source but not at when an agent should prefer this tool.

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 one genuinely useful behavioral fact - the data comes from the same order records as the advertiser portal, implying a single source of truth - but says nothing about auth requirements, freshness, or latency.

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 dense sentence with the verb, resource and scope front-loaded; every clause ('creative review, scheduled dates, live fulfillment') earns its place by telling the agent what the response covers.

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 an output schema present, return values need not be explained, and annotations carry the safety profile; the description covers the data source and the content domains. Only minor gaps remain, such as freshness or access prerequisites for a read of live fulfillment data.

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

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

Only one parameter and schema description coverage is 100%, so the schema fully documents advertisementId, including its provenance ('returned by save_campaign_draft'). The description adds no syntax or format detail beyond that, which is the correct baseline when the schema does the work.

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 a specific resource ('campaign and booking progress'), then scopes it with 'including creative review, scheduled dates and live fulfillment.' An agent can distinguish it from adjacent siblings like get_campaign_delivery or preview_campaign_plan, though the description never names those alternatives 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?

Usage is only implied: the tool is obviously the status-read entry point, and 'same order records as the advertiser portal' hints it is the parity/diagnostic source. There is no explicit when-to-use, when-not-to-use, or sibling routing, so an agent must infer the boundary against get_campaign_delivery.

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 and destructiveHint=false, so the safety profile is fully covered without the description. The description adds the notable detail that it reads the *exact current* state and includes creative readiness, which is real behavioral value beyond annotations, but there is no mention of auth needs, staleness, or cost of the call.

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 sentence with no filler, and the most decision-relevant element (the review-before-payment context) is placed at the end where it frames the whole call. Nothing is repeated from the title or schema.

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 no explanation, and the read-only/idempotent annotations mean the low-risk profile is adequate. The remaining gap is guidance on selecting among quoteId, quoteIds.owned/partner, bookingIds and providerLineIds, which neither the schema nor the description explains.

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 only 20% (only advertisementId is described) across five parameters, including a nested quoteIds object and three ID-list parameters whose relationship is unexplained. The description mentions no parameters at all, so it fails to compensate for the coverage gap that the rubric requires it to fill.

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 a concrete set of returned facts (selections, total, currency, creative readiness), and the 'before payment' framing separates it from create_campaign_checkout and preview_campaign_plan. It is clear but packs several noun phrases into one clause rather than crisply defining the resource.

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' implicitly places this in the pre-checkout step of the flow, which is useful sequencing context. However, no sibling is named (create_campaign_checkout, preview_campaign_plan, get_campaign_status are all plausible alternatives), so the agent must infer when to prefer this tool.

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 and destructiveHint=false, so the technical safety profile is covered. The description adds domain-level consequences beyond that: no inventory reservation and no advertiser charge, which is more concrete than a generic readOnly flag for an agent deciding whether this call has side effects. Auth requirements and rate limits remain unstated.

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 zero filler; the operative scope ('pricing and audience estimates') is front-loaded and the non-commitment caveat follows immediately. Nothing can 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?

An output schema exists, so return values need not be explained, and the annotations carry the safety profile. For a 20-parameter preview tool with two nested planning shapes (owned/partner vs. providerPlan), however, the description gives no routing guidance on which input mode to use, leaving a real gap against the tool's complexity.

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 20 parameters, only 20% schema description coverage, and deep nested objects (providerPlan, targeting.audience, geography), the description was obligated to compensate and does not. 'Selected screens and channels' loosely gestures at screenIds and providerPlan.channels, but source, quoteId, providerPlan vs. owned/partner budgets, audience targeting and geography handling are never addressed.

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 (preview) and resource (campaign plan) and states exactly what is computed: native campaign pricing and audience estimates for selected screens and channels. It is clear and distinguishable in substance from siblings like create_campaign_checkout or prepare_campaign_booking, though it never explicitly contrasts itself with them.

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?

Sentence two ('does not reserve inventory or charge') implies a pre-booking, exploratory step, which is a usable signal about when to call it. However, no alternative sibling is named and there are no explicit conditions or exclusions, so the guidance stays implied 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=false, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavioral context: the result is an *unpaid* campaign, creative lineage is preserved, prices are re-fetched, and a fresh review plus payment are required. That payment/review requirement is exactly the kind of extra context 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?

Two tight sentences with no filler, and the core operation (copy into a new unpaid campaign) is front-loaded before the lineage/price and review/payment consequences. 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 no explanation, and annotations cover safety and idempotency. The description supplies the key operational consequences (new unpaid campaign, fresh pricing, required review and payment). The only gap is eligibility — which prior campaigns can be rebooked and what happens to the original — leaving it just short of 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?

Schema description coverage is 100% with all four parameters documented, including the idempotency key retry semantics and the YYYY-MM-DD date pattern, so the baseline is 3. The description's 'for new dates' loosely maps to flightStart/flightEnd and 'previous campaign' to advertisementId, but it adds no format, constraint, or validation detail beyond what the schema already provides.

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 precise verb and resource: copy a previous campaign into a new unpaid campaign for new dates. The phrase 'copy a previous campaign' is specific enough to distinguish it from siblings like save_campaign_draft or prepare_campaign_booking, but it never names or contrasts those siblings explicitly, which is the only thing separating this from 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?

'Rebooking requires a new review and payment' signals a prerequisite, which is useful context for deciding whether to proceed. However, there is no explicit when-to-use vs when-not guidance, no statement of what campaign states are eligible for rebooking, and no routing to alternatives such as prepare_campaign_booking or save_campaign_draft.

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=false, destructiveHint=true and idempotentHint=true; the description's "save or update" is consistent with an upsert and adds the useful ownership/payer rule. However, a tool marked destructive that reads as a benign "draft save" deserves an explanation of what an update overwrites or deletes, and none is given.

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 action front-loaded and no filler. It is efficient, though the second sentence drifts into ownership policy rather than the operational constraints an agent most needs.

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 destructive, idempotent, 21-parameter upsert with deep nested targeting and an output schema, the description covers almost none of the decision-relevant surface: no note on partial vs full replacement, on required flight dates, on idempotency_key reuse, or on how owned vs partner inventory is selected.

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 21 parameters and only 24% schema description coverage, the description must compensate, yet it explains only clientName (client brief label) and vaguely gestures at partner/owned split via "agency remains the owner and payer." Flight windows, quoteId/quoteIds, screenIds, providerPlan, and the owned/partner budget and impression fields are left entirely to 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?

"Save or update an agency-owned campaign and selected inventory" gives a specific verb (upsert) and resource (campaign + inventory) plus the owning entity. It is clear but never contrasts itself with near-siblings such as prepare_campaign_booking or create_campaign_checkout, so an agent still has to guess which write path applies.

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 statement of when to call this versus the sibling booking/checkout/preview tools, nor any prerequisite (e.g., must a quote exist first, does this require prepare_campaign_booking). The only context given — agency owns and pays, clientName labels the brief — is ownership semantics, not usage routing.

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, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds two useful behavioral facts beyond that: results come from the advertiser portal inventory and are priced. It does not mention pagination (cursor) or result scope, so it only modestly exceeds what annotations provide.

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, verb-first, with no filler or repetition. It is appropriately sized, though for an 8-parameter tool with nested objects the brevity comes at the cost of leaving parameter guidance on the table.

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 cover the safety profile. However, for a tool with 8 params, a nested radius object, and only 38% schema coverage, the description omits pagination behavior, source semantics, and how radius interacts with city/query (which the schema flags as mutually exclusive). Adequate but with clear 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 description coverage is only 38% (city, query and radius carry descriptions), so the description should compensate and largely does not. Naming CTV/video/audio/display merely echoes the `channels` enum already in the schema, and nothing is said about source, state, cursor, limit, or the radius object semantics. With low coverage this leaves several parameters undocumented in either place.

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 ('Find') and resource ('local digital out-of-home screens and available CTV, video, audio and display products'), so an agent knows exactly what is being searched. It is naturally distinct from the campaign-management siblings (booking, checkout, preview, delivery) without naming them. A 5 is withheld only because the differentiation from siblings is implicit rather than stated.

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

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

The phrase 'for an agency client' gives loose context, but there is no when-to-use/when-not guidance, no prerequisites, and no mention of alternatives among the eight campaign siblings. The agent must infer that this is the inventory-discovery step that precedes prepare_campaign_booking or preview_campaign_plan.

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