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

Goes well beyond the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=false): it discloses the preview/confirm flow and that without confirm:true nothing changes, the full blast radius of the exclusion (Meta widgets, all-channels blends, comparison period, share links, PDFs, scheduled e-mails, get_report_data, widget aiNote), and the failure mode where >200 matching campaigns yields no figures and _meta.unavailable rather than unfiltered data. Requires-MCP-write-actions and the replacement semantics of the list are also stated.

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?

Front-loaded with purpose followed by the parameter detail, and nearly every clause carries information the caller needs. It is still long and the enumerated blast-radius list ('its Meta Ads widgets, the all-channels blends, the comparison period, share links, PDFs, scheduled e-mails and get_report_data...') could be tightened without losing meaning.

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?

No output schema exists, and the description does cover the failure surface and the preview token mechanics, which is most of what an agent needs. It does not, however, say what a successful confirm:true call returns (updated settings? the applied list?), leaving the success path underspecified for a mutation tool.

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

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

Schema coverage is 100% (baseline 3), but the description adds real semantics on top: the list is a full replacement not a merge, []/null clears the exclusion, terms are case-insensitive substring matches, trimmed and de-duplicated, and archived/deleted campaigns still count. One caveat: it states 'at most 20 terms of at most 100 characters' while the JSON schema hard-caps maxItems at 100 and item maxLength at 500 — the effective limit is inconsistent between prose and machine constraints.

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 ('Change a report's settings') and immediately narrows scope to settings 'that apply to all of its widgets', which cleanly separates it from widget-level siblings like edit_widget and from update_project_settings. The only setting exposed (excludeMetaCampaigns) is named explicitly, so an agent knows exactly what this tool mutates.

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 rather than stated: there is no explicit 'use this instead of edit_widget when...' routing, and no when-not-to-use. The one routing hint is 'get_report shows the current list (dateRange.excludeCampaigns)', which points at the read counterpart but is buried at the end of a dense paragraph. Adequate but clearly gapped.

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