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

With no annotations, the description carries the full burden and does disclose the key behavioral fact that this resumes ad spending (a real financial side effect) plus the gating prerequisites. It still omits permission/scope requirements, idempotency, and what happens on failure or if the campaign is already active.

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 tight sentences, front-loaded with the action, then the precondition, then the confirm workflow. No filler and no repetition of name or title.

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 mutation tool with no annotations and no output schema, the description covers the critical items: the spending side effect, prerequisites, and the confirm gate. It is still silent on return value, error conditions, and interaction with the bulk status sibling, so it is not fully 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?

Schema coverage is 0%, so the description must compensate. It does explain the non-obvious parameter, confirming exactly when and why to set confirm=True (after reviewing in Ads Manager), which the schema's bare boolean/default=false leaves unsaid; campaign_id is self-evident from its name but never described.

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 ("Activate (unpause) a Meta campaign") and disambiguates the terminology with the "unpause" synonym, which is genuinely useful. It does not distinguish itself from the sibling bulk_update_campaign_status, which can also change campaign status, so the sibling differentiation is incomplete.

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?

Gives concrete preconditions (valid payment method, approved creatives) and a workflow instruction (review in Ads Manager then set confirm=True). It does not say when to prefer this over bulk_update_campaign_status or what to do if the campaign is already active.

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?

With no annotations, the description carries the full burden and does well: it discloses that the operation is destructive-capable (delete), that dry_run defaults to True, and that a second explicit confirm=True flag is required to actually apply changes. It stops short of stating irreversibility of deletion or how many IDs are allowed per 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?

Four short lines, front-loaded with the action, then the enum constraint, then the safety workflow in the order an agent needs it. No filler sentences.

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 four-parameter mutation tool with no annotations and no output schema, the description covers the risky parts (status values, dry-run default, confirmation gate). The remaining gaps are the campaign_ids format/limits and what a dry run returns.

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 the description must compensate, and it documents three of four parameters meaningfully: the status enum values (PAUSED/ACTIVE/DELETED), dry_run's default of True, and confirm's role as the second gate. Only campaign_ids lacks format/limit detail.

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 set (pause, activate, delete) plus resource (campaigns) and the defining scope qualifier 'Bulk', which separates it from the single-campaign siblings pause_campaign/activate_campaign/delete_campaign. An agent can route bulk vs. single operations without opening a schema.

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 an explicit operating procedure: review the campaign IDs, then set dry_run=False and confirm=True. What is missing is a direct statement of when to prefer this over the single-campaign siblings, but the bulk scope plus the confirmation workflow gives clear context.

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?

No annotations are provided, so the description carries the full burden, and it does disclose meaningful behavior: dry_run=True simulates without spending money, dry_run=False actually deploys, confirm is the approval gate, and all campaigns start PAUSED. This is strong safety-relevant disclosure. It stops short of covering permissions/auth, rate limits, partial-failure or rollback behavior on multi-object creation, and what identifiers are returned.

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 purpose is front-loaded in the first line, followed by a tight bulleted parameter reference and enum lists; there is no filler or redundant restatement. Every block earns its place by documenting information the schema leaves blank.

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 an 11-parameter, money-spending mutation tool with no annotations and no output schema, the description covers the critical unknowns: dry_run/confirm semantics, pause-on-create default, and enum vocabularies. It omits what the call returns (campaign/ad IDs), failure semantics, and a few parameters, but the essentials for safe invocation are present.

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 the description must compensate, and it does substantially: it fully documents the nested ads dict fields (name, image_path, primary_text, headline, link, cta, description), explains daily_budget_cents with concrete examples (1000 = $10/day), and enumerates valid objective and CTA values. Gaps remain for optimization_goal, countries, age_min/age_max, and the two name params, which explain why this is not a 5.

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 first sentence gives a specific verb ('Create') and a compound resource ('a complete Meta ad campaign: campaign, ad set, creatives, and ads'), which precisely scopes it against the sibling list/update/pause/delete tools. An agent can immediately tell this is the only tool that provisions a whole campaign tree rather than reading or mutating an existing one.

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 the tool (creating a campaign) and gives workflow context: dry_run defaults to True and confirm is required to deploy. However, it never names alternatives or states explicit exclusions — e.g., whether image upload must precede this call given it accepts image_path, or how this relates to upload_ad_image. Usage is inferable but not spelled out.

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?

With no annotations, the description carries the full behavioral burden and does disclose the most important trait: deletion is permanent and cannot be undone. It also specifies the confirm requirement, though it omits side effects such as what happens to associated ad sets/ads and any permission or rate-limit considerations.

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 short sentences, front-loads the irreversible nature of the operation, and contains no wasted wording.

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 two-parameter tool with no annotations and no output schema, the core warning and confirm requirement are present. Completeness is limited by missing cascade/side-effect details and authentication or permission notes.

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 0%, so the description must compensate. It adds meaningful semantics for confirm by saying to set it True after reviewing the campaign ID, but it gives no format or validation detail for campaign_id beyond naming it.

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 and resource: "Permanently delete a Meta campaign." The word "permanently" implicitly distinguishes it from soft status changes like pause_campaign or activate_campaign, but it does not explicitly name any sibling alternative.

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 provides a concrete usage instruction: set confirm=True after reviewing the campaign ID. However, it does not say when to choose permanent deletion versus pausing, deactivating, or bulk status updates, so usage context is only partially implied.

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?

With no annotations, the description carries the behavioral burden and explicitly states 'Read-only,' which tells the agent this is a safe, non-mutating operation. It also lists the account attributes returned, though it does not discuss permissions, errors, or response structure.

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 short sentences with no wasted text, and the core action is front-loaded. The read-only note and usage guidance follow 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?

For a simple, zero-parameter read-only summary tool with no output schema, the description is complete enough: it states the action, safety profile, intended timing, and the specific fields being confirmed. Nothing essential for invoking this tool correctly 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?

The tool has zero parameters, so parameter semantics are not a meaningful gap. The baseline for a parameterless tool is 4, and the description appropriately adds no unnecessary parameter guidance.

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 and resource: 'Get the configured Meta ad account summary,' and enumerates the account-level fields it returns. It is clearly distinguishable from the campaign/ad-set/ad tools by its account-summary scope, though it does not explicitly name sibling alternatives.

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 a clear usage context: 'Use this before campaign work to confirm the connected account, currency, timezone, spend, balance, and account status.' It does not specify when not to use it or name alternative tools, but the intended pre-campaign verification use is explicit.

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?

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the returned payload (name, status, objective, ad sets and ads with statuses and budgets) and implies a read-only lookup via 'Get', but says nothing about permissions, rate limits, pagination, or error behavior for an invalid campaign_id.

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 short sentences, front-loaded with the action and followed by the return contents. Slight overlap between the 'status' in the first sentence and the return enumeration, but 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?

With no output schema, the description's enumeration of return fields is genuinely useful and covers the main gap. However, with no annotations and a bare 1-parameter schema, a complete definition would also address when to choose it over the sibling read tools and how to supply a valid campaign_id.

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 the description must compensate for the single campaign_id parameter and it largely does not. It only loosely contextualizes the value as belonging to 'a Meta campaign'; no accepted ID format or example is given.

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 (get the status of a Meta campaign) and clarifies that the result is an aggregate containing ad sets and ads, which separates it in spirit from list_campaigns/list_ad_sets/list_ads. It stops short of naming those siblings, so an agent must still infer the boundary.

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 required campaign_id implies you call this for one specific campaign rather than enumerating them, which weakly distinguishes it from list_campaigns. There is no explicit when-to-use, no exclusions, and no mention of alternatives such as get_ad_account_summary or the granular list_* 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?

With no annotations provided, the description carries the full burden, and it does add meaningful behavioral context by declaring 'Read-only' and explaining the object_id fallback behavior. It stops short of disclosing pagination, rate limits, date-range defaults, or what metrics are actually returned, which is a notable gap for a reporting tool with zero annotation coverage.

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 no filler, and the key scoping rule (object_id behavior) is front-loaded right after the purpose statement. Efficient, though the level sentence is vague enough to be of limited value.

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 4-parameter reporting tool with no annotations, no output schema, and 0% schema coverage, the description is thin: date_preset and limit semantics are unexplained, and the shape of the returned insights is not described at all. An agent would have to guess at date filtering and page size behavior.

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% and there are 4 parameters, so the description must compensate. It explains object_id's accepted entity types and partially clarifies level, but says nothing about limit (default 25) or date_preset (default last_7d), leaving half the parameters undocumented anywhere.

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 ('Get Meta Ads performance insights'), which is clearly distinguishable from sibling list/get tools like list_campaigns and get_ad_account_summary. It does not explicitly name which sibling to use instead, but the purpose itself is 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?

It gives two concrete usage rules: leave object_id blank to fall back to the configured ad account, and use level for account breakdowns. However, it never states when to prefer this tool over get_ad_account_summary or the list_* siblings, so routing between alternatives is left 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?

With no annotations, the description carries the burden; it does disclose 'Read-only', which is the key safety signal. It does not cover pagination, ordering/recency semantics, or what fields come back, leaving meaningful behavioral gaps for an unannotated tool.

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 short sentences, purpose front-loaded followed by usage and safety, 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 simple one-parameter list tool this covers purpose, safety, and intended use adequately. But with no output schema and an undocumented `limit`, an agent still lacks guidance on result volume and pagination behavior.

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 0% and the single `limit` parameter (default 25) is never mentioned. 'Recent ads' hints at ordering but the description does not explain what the limit controls or the default result size, so it fails to compensate for the schema 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 clear verb+resource ('List recent ads') scoped to the configured Meta ad account, which distinguishes it from list_campaigns/list_ad_sets by hierarchy level. It does not explicitly say how it differs from those sibling list tools, keeping it just 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?

'Use this to find ad IDs and inspect delivery status' gives a concrete task-oriented context for selecting the tool. No when-not-to-use guidance or explicit alternative is named, so it stays at 4 rather than 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?

With no annotations, the description carries full burden; it does declare read-only safety and the "recent" scoping plus configured-account constraint, which is valuable. However, it omits pagination behavior, ordering, and what the response contains.

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 short sentences, safety qualifier and usage hint front-loaded, zero waste.

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?

A simple single-param read tool is adequately framed for purpose and usage, but with no output schema the description should hint at returned fields/pagination, and it leaves the lone parameter undocumented.

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?

One parameter (limit) exists at 0% schema description coverage, and the description never mentions it. The tool has params, so the zero-param baseline of 4 doesn't apply; the agent gets no guidance on default or meaning of limit.

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 ("List recent ad sets") scoped to the configured Meta ad account. It's clearly distinct from list_campaigns and list_ads by resource, though it doesn't explicitly contrast with siblings.

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?

"Use this to find ad set IDs before budget or status changes" gives explicit context for when to call it. No exclusions or named alternatives, but the usage scenario is clear.

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?

No annotations are provided, so the description carries the full burden. It usefully declares 'Read-only', which is the key safety fact, but omits pagination behavior, ordering, or what 'recent' concretely means, so the disclosure is partial.

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 short sentences, front-loaded with the operation and then the routing guidance. No filler; 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?

For a simple list tool with no output schema and no annotations, it covers purpose, read-only nature, and workflow position. It is only missing detail on result limits and pagination, a minor gap rather than a blocking one.

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% and the description never mentions the single 'limit' parameter, its default of 25, or any cap on results. With low coverage the description should compensate but does not, leaving the sole parameter undocumented everywhere.

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 (List) plus resource (recent campaigns) scoped to the configured Meta ad account. An agent can immediately distinguish this from create_meta_campaign, get_campaign_status, or get_meta_insights without opening any schema.

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 routes the agent: use this to obtain campaign IDs before status, insights, budget, pause, activate, or bulk operations. This maps directly to the sibling tools and tells the agent exactly where this fits in a workflow.

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?

No annotations exist, so the description carries the full behavioral burden. It usefully discloses idempotency ('safe to call on already-paused campaigns'), but omits auth requirements, side effects (e.g., whether ad delivery/spend stops), reversibility, and response 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 short, front-loaded sentences with zero waste. The action is stated first, followed by the key safety note.

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 one-parameter mutation with no output schema, the description covers purpose and idempotency. It remains sparse on prerequisites and side effects, but the low complexity and lack of required return-value explanation keep this from being a major 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 0% and the description never mentions campaign_id, its format, or what it identifies. With one required parameter present, the description should compensate but adds no meaning beyond the schema.

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

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

States a specific verb 'pause' and resource 'Meta campaign'. Implicitly distinguishes from sibling activate_campaign (opposite action) and delete_campaign (destructive), but does not explicitly differentiate from bulk_update_campaign_status or address the odd 'live' vs 'already-paused' phrasing.

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 one explicit usage note: safe to call on already-paused campaigns. However, it offers no guidance on when to choose this tool over activate_campaign or bulk_update_campaign_status, nor any prerequisites.

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?

With no annotations, the description carries the full safety burden and does well: it discloses that dry_run defaults to True, that a confirm flag is required to apply a change, and that META_ADS_MAX_DAILY_BUDGET_CENTS caps the value. It does not say what the tool returns or how failures surface, but the mutation safety profile is clearly communicated.

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, front-loaded lines with no filler; the safe-default behavior comes first and the confirming step second. Efficient, though the env-var constraint could be folded into the invocation sentence.

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 mutation tool with no annotations, no output schema, and 0% parameter documentation, the description covers the critical dry-run/confirm workflow and the budget ceiling. Gaps remain around return behavior, error handling, and which object IDs are valid, which matter for a write operation.

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 the description must compensate. It explains dry_run and confirm semantics and ties the env-var cap to daily_budget_cents, but object_id is left unexplained (which ID type, campaign vs ad set nuance) and the unit/format expectations for daily_budget_cents are only implied by the name.

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 ('Update daily budget') and the two object types it applies to (campaign or ad set). It does not differentiate itself from siblings like bulk_update_campaign_status, but the purpose is 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?

Gives procedural guidance for the write flow (dry_run defaults True; set dry_run=False and confirm=True after review), which is actionable. However, it never says when to prefer this over sibling tools such as bulk_update_campaign_status or pause/activate_campaign, so selection guidance is only implied.

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?

With no annotations, the description carries the full burden and does disclose the most important behavior: the safe default (dry_run=True) and the fact that a real upload requires both flags to be flipped. It also reveals the return value (image hash). It omits permissions/auth requirements, file constraints, and whether a failed gated call still touches the remote account.

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 waste, with the core action front-loaded and the safety-gate instruction and return value following in priority order.

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?

There is no output schema, and the description compensates by naming the returned image hash. For a 3-parameter tool the safety gates, defaults, and return value are all covered; only input-file constraints and auth expectations are absent.

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 the description must compensate. It meaningfully explains dry_run and confirm, including how they interact to gate the upload, but says nothing about image_path semantics (format, relative vs absolute, existence checks) beyond what the bare schema shows.

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 ('Upload an image to the configured Meta ad account') and immediately clarifies the outcome (an image hash usable in ad creatives). It is trivially distinguishable from every sibling, which are all campaign/ad-set/insight management 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?

Gives clear when-to-use context by stating the artifact is for use in ad creatives, and spells out the activation condition for a real upload (dry_run=False and confirm=True). It does not mention that only non-dry-run calls mutate remote state or reference any alternative tool, so it falls short of full when/when-not guidance.

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