AdsAgent — Meta Ads MCP

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

Annotations already declare readOnlyHint=true, openWorldHint=false, destructiveHint=false, so the safety profile is fully carried by structured data. The description only adds the 'login identity only' scoping boundary. With an output schema present, there is little else for the description to disclose; a 3 is appropriate.

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 fragments, front-loaded with the scope statement before the routing hint. No wasted words. It is arguably clipped to the edge of intelligibility, but every token 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 zero-parameter read tool with a full output schema and complete annotations, the description covers the only thing the schema and annotations cannot convey: what this profile represents (login identity) and where the alternative lives. Adequate, if terse.

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 takes zero parameters, so there is nothing for the description to compensate for. Baseline 4 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?

States the exact scope of the resource: the login identity profile, and contrastively marks what it does not cover. An agent can distinguish it from setup_get_status and account_media_* siblings. No explicit verb, but the name plus scope makes the operation 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?

The description gives a clear routing rule: use this for login identity, use setup_get_status for channel setup. It names the alternative and the condition that selects it, though it never states why an agent would need the login identity in the first place.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered without the description. The description adds no further behavior beyond that — nothing about resolution failures, what an invalid media_ref yields, or how connection_context scopes the read. Given the annotation coverage this is acceptable but thin.

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 clause plus a semicolon-delimited routing note. Zero filler, and the core action is front-loaded before the alternative is mentioned.

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 safety profile. What remains missing is parameter meaning, particularly the opaque connection_context token and the provenance of media_ref, which an agent would need to call this correctly.

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% for both parameters, so the description carries the burden and does not meet it. It never explains the media_ref format (the schema's own pattern hints at a 'media_e1.' prefix but no rationale) or what connection_context is used for. The generic phrase 'account media reference' is the only semantic hint provided.

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 and resource ('Read one account media reference'), and the word 'one' cleanly separates it from the batch sibling. It does not explicitly distinguish itself from account_media_list, but the singular/plural framing makes the distinction inferable.

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 routing rule: 'prefer account_media_get_batch for multiple selections'. That is a real when/when-not statement tied to the count of selections. It stops short of mentioning account_media_list or any prerequisite about the media_ref origin.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds the 50-item batch ceiling and the intended workflow position, but says nothing about cursor behavior for pagination, partial failures, or connection_context validation. Useful context, but not rich beyond annotations.

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 wasted words; the count constraint and the workflow hint both earn their place. It is slightly telegraphic ('after listing the index' could be clearer) but never padded.

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 safety profile. The batch cap and ordering guidance complete the core picture for a read-only batch fetch; only cursor/pagination semantics and connection_context usage remain 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 0%, so the description carries the full burden, yet it only loosely gestures at media_refs ('selected ... previews') and the maxItems=50 ceiling. The cursor and connection_context parameters, including the mctx_v1_ token format, are left entirely unexplained by both schema and description.

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

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

States a specific verb+resource ('Fetch ... account media previews in a batch'), includes the batch size constraint, and distinguishes itself from the single-item sibling by naming the anti-pattern it replaces ('avoid serial item probes'). An agent can separate it from account_media_get and account_media_list 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?

Gives clear sequencing ('after listing the index') and an explicit when-not ('avoid serial item probes'), which routes the agent away from repeated account_media_get calls. It stops short of naming the sibling tool explicitly or stating prerequisites such as the media_refs format 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 readOnly, non-destructive, non-openWorld, so the safety profile is covered. The description adds the 50-entry page size and the candidate-selection pattern, which is real context, but says nothing about cursor paging behavior or what the policy check actually gates.

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?

Extremely short and action-first: the verb and resource lead, the follow-up tool comes second. Nothing is padded, though 'Check setup_get_status policy' is terse to the point of being cryptic.

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. However, for a 5-parameter tool with zero schema descriptions and pagination, the definition leaves key invocation details (cursor usage, media_type semantics, policy precondition mechanics) unstated.

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% across 5 parameters, so the description carries the burden. It only conveys the implicit 50-item limit; media_type, ad_account_id, cursor, and the connection_context pattern are left entirely undocumented.

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 account media index entries, capped at 50. It also signals scope by naming account_media_get_batch as the follow-up, so an agent can place it in the media workflow. 'Index entries' is slightly jargon-y and it doesn't fully differentiate from account_media_get.

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 an explicit two-step workflow — list to select candidates, then call account_media_get_batch — and points at setup_get_status as a policy precondition. That is clear usage context, though it phrases the policy check vaguely with no when/when-not conditions.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds nothing beyond that: it does not explain what "token provenance" means, whether owner resolution requires elevated permissions, or what the tool returns when no owner is found.

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 six-word phrase with zero filler, and the object of the operation is front-loaded. It is efficient but under-specified rather than genuinely concise, providing no structure to hang behavior or parameters on.

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 explanations are not required. Even so, for a tool with a required account ID, a hidden operation mode, and a pattern-constrained context token, the description leaves the agent without enough to invoke it confidently or interpret what it is really doing.

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% across three parameters, and the description supplies no parameter information at all. Most damaging is the undocumented "operation" parameter: its default is "pull" but no alternative values are named anywhere, and the constrained "connection_context" pattern is likewise 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?

The phrase names a verb ("Find") and two targets ("account owner" and "token provenance"), so the intent is roughly graspable. However, "token provenance" is undefined jargon, and nothing distinguishes this from siblings like accounts_get_account_detail or account_get_profile, which an agent could plausibly pick instead.

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 routing to alternatives, despite ~130 sibling tools including several that appear to return account-level information. The agent gets no signal about when this tool is the right choice.

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/openWorldHint/destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context beyond them: app bindings are cached (data-freshness/staleness signal) and BM links are deliberately excluded from the result. That is useful disclosure not present in 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?

Two tightly packed sentences with the core action and the two key qualifiers (cached, no BM links) front-loaded before the topology pointer. The trailing 'BM topology: assets_lookup_business_links' is terse to the point of being cryptic, but nothing is wasted.

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 annotations cover safety for this read-only tool. The gap is parameter-level: with 0% schema coverage the agent gets no guidance on connection_context or the expected id form, leaving the definition only minimally adequate.

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% across two parameters, and the description explains neither ad_account_id nor connection_context (which carries a regex constraint the agent cannot interpret from prose). 'Authorized in your workspace' loosely gestures at connection_context but adds no usable semantics, so the description fails to 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?

The description uses a specific verb and resource ('Read live Meta details for one ad account'), and adds scope ('authorized in your workspace'), which separates it from bulk listings like assets_list_ad_accounts. It is clear but does not explicitly contrast with near-neighbors like account_get_profile or accounts_find_owner, 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?

Usage is implied rather than stated: the 'no BM links' qualifier plus 'BM topology: assets_lookup_business_links' effectively routes the agent elsewhere for business-manager topology. However, there is no explicit when-to-use/when-not framing against the sibling reads (account_get_profile, accounts_find_owner), leaving the agent to infer the boundary.

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, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds only the 'snapshot read' qualifier, hinting at point-in-time/cached semantics but not explaining freshness, pagination, or result limits. A modest addition on top of annotations.

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 tight sentence with the scope qualifier front-loaded after the verb. No filler, no redundancy, easy to scan.

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 safety profile. However, the undocumented connection_context parameter and the absence of any routing guidance against similar page/account listing tools leave gaps for a tool in a dense sibling namespace.

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% for 2 parameters, so the description carries the burden. It only loosely gestures at ad_account_id ('on one ad account') with no format details, and connection_context is never mentioned anywhere, leaving a required-looking contextual parameter entirely undocumented.

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) and resource (pages eligible for ad creation) scoped to one ad account. It does not explicitly differentiate from near-siblings such as assets_list_pages, but the 'eligible for ad creation' framing gives it a distinct purpose an agent can recognize.

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 guidance on when to prefer this tool over assets_list_pages or accounts_list_instagram_accounts, nor any stated prerequisites or exclusions. The phrase 'on one ad account' only implies that an ad account context is required, which the schema already enforces.

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, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond that baseline – no pagination behavior, no rate-limit note, no hint about what the IDs reference, so it earns only a minimal score.

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 words is under-specification rather than conciseness. There is no wasted text, but there is also no substance, so brevity here signals missing information rather than efficient communication.

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 spelled out, and annotations cover the safety profile. However, for a read tool with five mostly undocumented parameters and a near-identical sibling, the description leaves the agent unable to distinguish, scope, or correctly parameterize the call.

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 0% schema description coverage, and the description explains none of them. The required ad_account_id and page_id, plus limit, cursor, and connection_context, are entirely undocumented, so the description fails to 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?

"List IG IDs" is a near-tautological restatement of the tool name (accounts_list_instagram_accounts) in abbreviated form. It gives a verb and resource but no scope, no distinguishing detail from the very similar sibling assets_list_instagram_accounts, and "IG IDs" is ambiguous about what is actually returned.

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 provides no when-to-use guidance, no prerequisites, and no indication of when to prefer this over assets_list_instagram_accounts or accounts_list_linked_accounts. An agent has nothing to route on.

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, destructiveHint=false, openWorldHint=false, so safety is covered. The description adds value beyond that by explaining that 'refresh rereads stored rows' and by explicitly ruling out syncing Meta, queueing work, and saving snapshots — a meaningful behavioral boundary for a stored-data reader. No rate limits or freshness caveats, so not a 5.

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?

Very dense and front-loaded: purpose first, then filtering/pagination, then the refresh caveat and exclusions, then the sibling pointer. Every fragment carries information, though the telegraphic style ('Filter then paginate', 'BM links: ...') trades some readability for brevity.

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. The gap is parameters: with 0% schema description coverage across 6 params, the description leaves fb_user_label and connection_context undocumented, so an agent cannot fully reason about invocation. Adequate but incomplete.

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 carry the parameter burden. It explains 'refresh rereads stored rows' and implies search/cursor/limit via 'Filter then paginate,' but fb_user_label and especially connection_context (a patterned opaque token) are left entirely unexplained. Partial compensation for a 6-parameter 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 and resource: 'Read linked Meta ad accounts and their Facebook connection labels from stored workspace routing.' The 'linked ... from stored workspace routing' qualifier helps distinguish it from assets_list_ad_accounts and accounts_get_account_detail, and it names assets_lookup_business_links as the sibling for BM links. It stops short of explicitly contrasting with the nearest sibling, keeping it at 4.

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 operational guidance ('Filter then paginate') plus negative routing: 'this tool does not sync Meta, queue work, or save snapshots,' and points to assets_lookup_business_links for BM links. No explicit statement of when to prefer this over assets_list_ad_accounts, but the exclusions and alternative reference are real guidance.

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

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

The description goes beyond the annotations by disclosing the two-phase approval workflow, the return values (approval_ref, plan_digest), and that 'This call does not change delivery.' The annotations declare readOnlyHint=false and destructiveHint=false, and the description is consistent with that. It doesn't mention auth/permission requirements for the Meta account read.

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 compact sentences, front-loaded with the core purpose, then the approval/confirm flow, then the preferred alternative. Every sentence carries operational meaning 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 two-phase mutation with an output schema present, the description fully explains the workflow and point-of-no-return. The main gap is parameter semantics (0% schema coverage) for a required adset_id/bid_amount/ad_account_id triple. It correctly relies on the output schema for return-value structure.

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 all four parameters are undocumented anywhere. The description mentions none of adset_id, ad_account_id, bid_amount, or the connection_context pattern, leaving the agent to infer that 'one ad set' maps to adset_id and bid-amount sizing to bid_amount. This is insufficient compensation for a 0% coverage 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?

The description opens with a specific verb+resource+scope: 'Prepare one ad set bid-amount change: read current Meta settings ... and save an approval draft.' An agent can distinguish it from adsets_prepare_budget_change and adsets_prepare_status_change by the operation type (bid amount) and from operations_confirm_adset_bid by the prepare/apply split.

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 explicitly states 'apply only after approval with operations_confirm_adset_bid' and 'Prefer entities_prepare_update for new work', giving both the confirm step and an alternative tool. It lacks a clear when-not condition beyond the entities_prepare_update pointer.

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 readOnlyHint=false the annotations only say 'not read-only'; the description adds the genuinely useful nuance that this call writes an approval draft but does not change delivery, and names the artifacts returned (approval_ref, plan_digest) that the confirm step consumes. It does not disclose whether the draft expires, requires permissions, or what happens on concurrent drafts.

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 front-loaded sentences with the core action, the return artifacts, and the safety note packed in; little waste. The trailing 'Prefer entities_prepare_update for new work' is slightly cryptic and appended rather than integrated, but the description is well within an appropriate size.

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?

The workflow contract (prepare then confirm, no delivery change) is complete enough for correct invocation, and an output schema covers return values. However, with 0% parameter documentation and an ambiguous alternative-tool pointer, an agent still lacks guidance on how to fill the inputs correctly.

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 adset_id, ad_account_id, daily_budget, or connection_context. Only 'daily-budget change' faintly implies the daily_budget parameter; the ID and connection_context parameters are entirely undocumented in both places.

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 ('prepare') plus a precise resource and scope ('one ad set daily-budget change'), and describes the two-phase action (read Meta settings, save an approval draft). This cleanly separates it from siblings adsets_prepare_bid_change and adsets_prepare_status_change without needing the 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?

Gives a clear sequencing rule: apply only after approval via operations_confirm_adset_budget, and points to entities_prepare_update for new work. It lacks an explicit when-not-to-use condition (e.g., vs. campaigns_prepare_budget_change for campaign-level budgets), and the entities_prepare_update guidance is vague about what 'new work' means.

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 only say readOnlyHint=false/openWorldHint=true/destructiveHint=false; the description adds meaningful context by clarifying that this call 'does not change delivery' and that it saves an approval draft rather than mutating live state, plus what the call returns (approval_ref, plan_digest). It still doesn't disclose the authorization/scope requirements hinted at by 'your authorized 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?

Roughly four short clauses, all front-loaded with the core action first, then return values, then safety note, then alternative. 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?

An output schema exists so return structure need not be explained, and the description still names the returned references and the approval handoff, covering the prepare/confirm workflow. The main gap is the complete absence of parameter-level information given 0% schema coverage.

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% across 4 parameters, and the description adds nothing about adset_id, ad_account_id, target_configured_status (enum ACTIVE/PAUSED), or the connection_context pattern. The description does not compensate for the schema's missing parameter documentation.

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 (prepare) and resource (ad set status change) with clear scope ('one ad set status change') and contrasts it with the follow-up tool operations_confirm_adset_status, so an agent can distinguish it from the many other prepare_* 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?

Explicitly says to apply only after approval via operations_confirm_adset_status and to prefer entities_prepare_update for new work, which gives both sequencing and an alternative. However, the phrase 'for new work' is vague about the exact boundary between this tool and entities_prepare_update.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the useful batch constraint of 1-50 ads and the scope of returned content, which the annotations do not provide. Still terse and silent on error/auth behavior for the connection_context.

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 phrase with the verb first and no wasted words. Efficient, though extremely terse for a tool with an undocumented 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 described, and the annotations cover the read/safety profile. The description handles the batch-size and content scope adequately but leaves the connection_context parameter and any usage guidance 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?

With 0% schema description coverage, the description must carry parameter meaning. It hints at ad_ids cardinality ('1-50 ads') but never explains the connection_context token or the id format, leaving a required contextual parameter entirely undocumented.

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?

Uses a specific verb (Read) and resource (stored copy of ads), and enumerates the content returned (texts, links, button, Page, preview, type). This clearly separates it from the write-side siblings like ads_update_copy_prepare/confirm, though it never names an alternative. Clear but lacks explicit sibling differentiation.

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 'stored copy' implies this reads a cached/persisted snapshot rather than fetching live, which is an implied usage context. However, there is no explicit when-to-use, no prerequisites, and no mention of alternatives such as creatives_get or the update flow.

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

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

Annotations declare readOnlyHint=false and destructiveHint=false, so the description's clarification that 'this call does not change delivery' is valuable added context explaining the draft-only nature. It also names the returned approval_ref and plan_digest, going beyond the annotation surface.

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 compact sentences: purpose first, then the return/approval path, then the non-delivery assurance and alternative. No filler; every clause conveys actionable 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 needn't be re-explained, and the approval workflow is fully described. The main gap is the unexplained connection_context parameter, which the description ignores.

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 carries the full burden for four parameters, yet it explains none. The ad_id, ad_account_id, and especially the connection_context token format (a regex-constrained mctx_v1 string) are left entirely to the raw schema; only target_configured_status is self-documenting via its enum.

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 ('prepare one ad status change') and situates it as stage one of an approval workflow. It is clearly distinguishable from sibling prepare/confirm tools like adsets_prepare_status_change and operations_confirm_ad_status.

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: 'apply only after approval with operations_confirm_ad_status' and 'prefer entities_prepare_update for new work.' The when-to-use is clear, though the 'new work' phrasing is slightly ambiguous about exactly when the alternative applies.

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 destructiveHint=true and openWorldHint=true, so the safety profile is known. The description adds meaningful context by specifying the swap is 'in-place' (the ad is mutated rather than recreated), but it omits that the operation is irreversible, what the confirm_token is bound to, and its likely single-use nature.

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. However, the brevity shades into under-specification for a destructive, token-gated operation rather than being sharply efficient.

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, but for a destructive confirm step the description is silent on prerequisites, token provenance, reversibility, and the deny alternative. Given the complexity and the crowded prepare/confirm/deny sibling set, this is too thin.

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% across two parameters. The description says nothing about confirm_token (its origin, lifetime, or single-use semantics) or connection_context, so it fails to compensate for the total absence of schema documentation.

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 (confirm) and resource (creative swap) with the scope qualifier 'in-place'. An agent can tell it is the execution step of a swap flow, but the description never names its siblings (ads_replace_creative_prepare/deny, ads_replace_page_confirm) to disambiguate between the near-identical prepare/confirm/deny families.

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 word 'approved' faintly implies a prior approval/prepare step, but there is no statement of when to call this versus ads_replace_creative_deny, whether prepare must run first, or where the token originates. No explicit when/when-not guidance 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?

The annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description adds the useful nuance that the target is a 'prepared' (pending) swap rather than a live entity, but says nothing about what denying does to that pending state or whether the operation is reversible.

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 phrase with no filler, so every word earns its place. It is arguably too terse for a destructive mutation, but structurally it is clean and non-redundant.

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. However, for a destructive mutation with 0% schema coverage, the description omits the prepare/confirm/deny workflow context, the meaning of confirm_token, and the effect of denial, 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 0%, so the schema only gives types: a required confirm_token string and a pattern-constrained connection_context. The description explains neither parameter, leaving the agent without guidance on what confirm_token is or where it comes from.

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 ('Deny') and resource ('prepared in-place creative swap'), so an agent can tell it is the rejection counterpart to a prepare/confirm flow. It does not explicitly name its sibling ads_replace_creative_confirm or ads_replace_creative_prepare, so it stops short of full differentiation.

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 mention of the prepare/confirm/deny workflow, and no condition distinguishing deny from simply ignoring or confirming a prepared swap. Usage is only implied by the verb 'Deny'.

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, openWorldHint=true, and destructiveHint=false, so the safety profile is partly covered. The description adds only 'in-place' (mutates the existing ad) and 'library-creative' source, but omits the critical trait that this is a staging step whose effect requires a separate confirmation, which no annotation reveals.

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?

It is a single front-loaded sentence with no wasted words, which is structurally clean. However, for a 9-parameter mutation tool it is under-specified rather than genuinely concise, leaving all detail to unannotated, undescribed fields.

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, but for a 9-param write tool with 0% schema coverage and no annotation detail, the description omits the two-phase workflow, the meaning of the input fields, and any side-effect context. It is not complete enough 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 0% across 9 parameters, and the description clarifies none of them. The tool has heavily ambiguous overlapping parameters (ad_id vs account_id vs ad_account_id; creative_name vs creative_names vs new_creative_name vs replacement_creative_name), and the description provides zero disambiguation, so it fails to 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?

The description names a specific verb+resource: 'Prepare ... creative swap on an existing ad,' with 'in-place' and 'library-creative' scoping the target and source. It is clearly a preparation step, but it does not distinguish itself from the sibling confirm/deny tools that the name pattern implies, so a 5 is not warranted.

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 prerequisite (e.g., you must later call ads_replace_creative_confirm to apply the swap), and no mention of the prepare/confirm/deny siblings. An agent gets no routing information from the description.

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 destructiveHint=true, readOnlyHint=false, openWorldHint=true, covering the safety profile. The description adds the useful nuance that the swap is 'in-place' and requires prior approval, but does not disclose what is destroyed or remediation if the token is invalid.

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; efficient and easy to parse. It is arguably too terse for a destructive confirmation step, but nothing in it is wasted.

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?

Output schema exists, so return values need not be explained, and annotations cover the mutation profile. Yet for a destructive confirmation tool the critical confirm_token and connection_context semantics and the prepare/confirm/deny workflow context are 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 description coverage is 0%, so the description carries the full burden for two parameters. It hints at an approval token via 'approved' but never ties that to confirm_token, and connection_context (with its strict mctx_v1 pattern) is entirely unaddressed.

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 (confirm) and resource (in-place page swap), which is clear enough to distinguish it from the deny and prepare steps. However, it never names the sibling tools (ads_replace_page_prepare/deny) that define the workflow it belongs to.

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?

"Confirm an approved page swap" implies the tool is used after a prior approval/prepare step, giving implicit usage context. But it does not state explicitly when to call this vs. ads_replace_page_deny or ads_replace_page_prepare, nor what precondition (an approved token) must exist.

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 and destructiveHint=true, so the safety profile is covered. The description adds nothing beyond that – it does not say what denying actually does (discards the prepared swap? cancels a token? notifies a counterparty?) or whether it is reversible.

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 short, front-loaded phrase with no filler. Its brevity is efficient, though it is arguably under-specified rather than genuinely concise given the gaps elsewhere.

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 mutation tool in a confirm/deny pair with 0% parameter coverage, the description omits the workflow context and token semantics an agent needs to invoke it correctly.

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% for two parameters, so the description must carry the burden and does not. It never explains what confirm_token is, where it comes from, or what connection_context is for – both are undocumented in schema and description.

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

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

States a specific verb ('Deny') and resource ('a prepared in-place page swap'), which cleanly separates it from the confirm/prepare siblings in the naming. It stops short of explicitly naming the sibling it pairs with (ads_replace_page_confirm) or describing the workflow, so it is clear but not fully differentiated.

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?

No when-to-use guidance: nothing about the prepare→confirm/deny lifecycle, when denying is appropriate, or what state the operation must be in. The agent must infer the workflow from sibling names alone.

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

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

Annotations declare readOnlyHint=false, openWorldHint=true, destructiveHint=false, so the description doesn't need to repeat safety. It adds the key non-obvious behavior that media may be uploaded to Meta and that confirmation is a separate step, going beyond annotations. It doesn't mention permissions or what the prep returns, but with annotations and an output schema, this is a solid 4.

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 a crucial side-effect warning. No wasted words, though the extreme brevity means some necessary detail is omitted, which is more an under-specification issue than verbosity.

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 9-parameter mutation tool with 0% schema coverage, the description is too sparse. It omits parameter guidance, preconditions, and the prepare/confirm workflow context, leaving the agent to infer too much from an output schema that describes only results, not inputs.

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% (9 params, none documented), so the description carries full burden. It mentions no parameters at all—not ad_id, ad_account_id, nor the multiple page ID fields—and doesn't clarify their relationship. This is a significant gap for a 9-param tool.

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 verb and resource ('Prepare page swap') but is terse and doesn't distinguish it from siblings like ads_replace_creative_prepare or ads_replace_page_confirm. 'Page swap' is clear enough, but the tool's specific role in the prepare/confirm workflow is only implied.

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 'Confirm separately to apply' signals that this is a preparatory step and that ads_replace_page_confirm is required to finalize, which is useful. However, it doesn't explicitly state when to use this versus other prepare tools or what preconditions must hold.

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 openWorldHint=true, so the safety profile is known. The description adds one useful behavioral detail – that the call reads back the copy on the same Ad ID after confirming – but omits what specifically changes, reversibility, or auth requirements.

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 compact sentence with the confirmation action front-loaded and the read-back behavior trailing. Nothing is wasted, though the sentence is terse enough to feel slightly under-specified rather than optimally dense.

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 explanation is not required, and the read-back note covers the response shape informally. Still, for a destructive confirm operation with 0% parameter coverage and no stated preconditions, the description leaves 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 0%, so the description must carry parameter meaning, and it does not. Neither confirm_token (how it is obtained, its lifecycle) nor connection_context is explained, leaving the required parameter entirely opaque.

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 (confirm) and resource (approved copy edits), plus an extra behavioral note ('read back copy on the same Ad ID'). The 'confirm' framing clearly separates it from the ads_update_copy_prepare/deny siblings, though it never names them 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 implied by 'Confirm approved copy edits' – the agent can infer this is the approval step after a prepare flow. However, no explicit when-to-use, prerequisites (e.g., a prior prepare call producing confirm_token), or alternative paths are 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 destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description usefully clarifies that the ad itself is not modified (only prepared edits are discarded), but it omits the dependency on a prior prepare step and any permission/auth context.

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; the core action and key constraint appear immediately. It is tight, though perhaps terse to the point of under-specification.

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 and annotations cover return values and safety, but for a deny step in a multi-stage flow the description should at least connect to the prepare/confirm siblings and explain the required confirm_token. As written, an agent lacks the context needed to invoke it correctly.

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 required confirm_token plus connection_context are entirely undocumented. The description adds no parameter meaning at all, so it fails to compensate for the coverage gap on a required parameter.

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 ('discard prepared copy edits') and adds the differentiating constraint 'without changing the ad', which separates it from the confirm counterpart. It is clear what the tool does, though it never names the sibling ads_update_copy_confirm 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 description implies the deny path of a prepare/confirm/deny flow but never states when to use this versus ads_update_copy_confirm or ads_update_copy_prepare. No prerequisites, no explicit when-not guidance; usage is inferred from the name and the sibling set.

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

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

Annotations declare readOnlyHint=false, destructiveHint=false, openWorldHint=true, so the safety profile is partly covered. The description adds useful context that media and Page are preserved (a partial-update trait) beyond what annotations state. However, it omits the central behavioral fact that this only stages edits and applies nothing until a separate confirmation.

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 wasted words; the constraint is placed immediately after the action. It is efficient, though its brevity is also the source of the missing workflow detail rather than deliberate compression.

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 mutation tool with 0% parameter coverage the description is thin. It fails to convey the two-phase prepare/confirm workflow that governs correct invocation, leaving the agent without the context needed to complete the operation safely.

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 carry parameter meaning and it only partially does. It names the three editable fields (body/title/description) but says nothing about ad_id beyond 'same Ad ID', nor about ad_account_id or the opaque connection_context parameter. Required-field semantics remain undocumented.

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 (Prepare) plus the fields being edited (body/title/description) and the key constraint (same Ad ID, preserving media and Page). This distinguishes it from the sibling ads_update_url_prepare and ads_replace_creative_prepare. It does not explicitly signal its role as stage one of the prepare/confirm/deny sequence, but the intent is clear.

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?

No when-to-use guidance and no routing to complementary siblings. Critically, it never tells the agent that this is a staging step that must be followed by ads_update_copy_confirm (or abandoned via ads_update_copy_deny), nor how it differs from the read-oriented ads_get_copy. Usage must be inferred entirely.

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=false, openWorldHint=true, so the safety profile is partly covered. The description usefully adds that this is a staging step whose effect is gated on a later confirm/deny, but it says nothing about permissions, idempotency, or whether an unconfirmed prepare 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?

One compact sentence with the action front-loaded and the workflow hint attached; nothing is padded. It is arguably too terse for a 4-parameter mutation-prep tool, but no sentence wastes space.

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 key workflow fact (confirm/deny via operations) is present, but with 0% schema coverage on the inputs and no mention of the account scoping or connection context, the definition is only minimally complete for calling the tool correctly.

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 carry the param burden. It only hints at ad_id ('same Ad ID') and destination_url ('destination URL change'), leaving ad_account_id and the connection_context token pattern entirely unexplained. Two of four parameters get no added meaning.

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 (Prepare) and resource (a destination URL change on the same Ad ID), which an agent can distinguish from the copy/creative/status prepare siblings. It does not name the exact sibling tools, but the 'confirm/deny via operations' phrasing points at the correct downstream family.

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 the prepare-then-confirm workflow and points to 'operations' for the confirm/deny step, but never states when to choose this over ads_update_copy_prepare or ads_prepare_status_change, nor any prerequisites. Usage is implied rather than 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?

Annotations declare non-read-only, non-destructive behavior. The description adds meaningful context beyond annotations: cache miss or authorized refresh may queue private work (async side-effect) and results include routing flags. No auth or rate-limit details, but the added behavioral nuance is valuable.

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 and the description is short, but it uses semicolon-separated fragments and ends with a dangling 'assets_lookup_business_links' that lacks a verb or clear relational context, reducing structural clarity.

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 and annotations exist, so return values need not be described. Yet with 6 undocumented parameters and weak usage guidance, the description is not complete enough for an agent to confidently invoke it, especially regarding fb_user_label and connection_context.

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% for 6 parameters. The description only vaguely alludes to filtering and pagination (search/limit/cursor) and to refresh behavior; parameters like fb_user_label and connection_context are entirely unexplained, so it fails to compensate for the missing schema documentation.

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', resource 'Meta ad accounts', and scope 'this workspace can use'. Mentions routing flags and references a related tool (assets_lookup_business_links), aiding differentiation, though other assets_list_* siblings are not explicitly contrasted.

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 operational guidance ('filter then paginate') and a dangling sibling reference, implying usage. However, it does not state when to use this tool versus alternatives such as assets_list_businesses or assets_search_mentions, nor any when-not conditions.

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

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

Annotations declare readOnlyHint=false on a list operation, which is counterintuitive; the description resolves this by disclosing "Cache miss/authorized refresh may queue private work." That explains the non-read-only nature and is genuine value beyond the annotation flags. It does not, however, describe pagination or rate implications.

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 the purpose, which is good, but the trailing clauses read as telegraphic fragments ("filter then paginate; assets_lookup_business_links") whose meaning is left to inference. Small but not tight.

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, but with 0% parameter coverage and a non-read-only mutation-adjacent behavior (queued private work), the description leaves the agent without enough to invoke the tool confidently.

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% across 6 parameters, so the description must carry the load. "filter then paginate" loosely maps to search and cursor/limit, but refresh, fb_user_label, and connection_context are undocumented in both schema and description.

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

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

States a specific verb+resource ("List Meta Business Managers") and scopes it to "visible to this workspace." It is distinguishable from siblings like assets_list_pages or assets_list_ad_accounts by resource, though it does not explicitly name a same-domain alternative to route away from.

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?

"filter then paginate" and the trailing fragment "assets_lookup_business_links" imply ordering and a related tool, but neither is framed as a when-to-use/when-not rule. No exclusions or prerequisites are 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, destructiveHint=false and openWorldHint=false. The description does add one useful behavioral fact the annotations do not carry: results come from a cache ('cached'), implying possible staleness. That said, it omits pagination semantics despite exposing a cursor parameter.

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 short sentence with no filler. It is well front-loaded but arguably too terse for a five-parameter tool with no documented parameters.

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 with five undocumented parameters, no usage routing, and no pagination/filter explanation, the definition is incomplete 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?

Five parameters (limit, cursor, search, ad_account_id, connection_context) at 0% schema description coverage, and the description explains none of them. It does not even hint at filtering by ad account, search, or pagination, so the description 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 specific verb (list) and resource (Instagram IDs and names), plus the source of truth ('Auto Pull Assets'). It does not distinguish itself from the near-identical sibling accounts_list_instagram_accounts, so an agent cannot tell the two apart from the text alone.

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 guidance on when to use this versus the many sibling list tools (assets_list_pages, assets_list_ad_accounts, accounts_list_instagram_accounts). No prerequisites, no indication of when the cache is stale or must be refreshed via assets_refresh_* 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?

Annotations declare readOnlyHint=false for a list operation, and the description supplies the missing rationale: 'Cache miss/authorized refresh may queue private work.' This is genuine behavioral disclosure beyond the structured fields and explains why a 'list' tool is not marked read-only. It does not, however, characterize latency or the queued work's lifecycle.

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 and the text is compact, but the telegraphic semicolon chain and the orphan token 'assets_lookup_business_links' with no verb or connector make the routing hint hard to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, and the readOnlyHint=false behavior is covered. But for a 6-parameter tool with zero schema coverage, the description omits enough parameter meaning that an agent cannot reliably construct a call.

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% across 6 parameters, so the description must carry the load, yet it only vaguely gestures at filtering and pagination (search/cursor) and says nothing about limit, refresh, fb_user_label, or the connection_context pattern. Most parameters remain undocumented in both places.

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 with scope: 'List Facebook Pages this workspace can advertise with, with health.' Clear what it returns, but it does not distinguish itself from close siblings such as assets_list_ad_accounts, assets_list_businesses, and assets_list_instagram_accounts, so an agent must still infer which list to call.

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?

'filter then paginate' implies a workflow, and the trailing 'assets_lookup_business_links' hints at a related tool, but neither is expressed as an explicit when-to-use or when-not-to-use rule. Usage is 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 readOnly/openWorld/destructive hints, so the safety profile is covered. The description adds real value beyond that: it flags the data is cached, warns 'Snapshot edges may be incomplete,' and states 'no match does not prove no relationship or ownership' — an important false-negative caveat — plus an 'OAuth-safe' note.

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 sentences, front-loaded with the purpose and then the selector constraint and the caveat. No filler. Slightly dense but 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 explained. Combined with the annotations, the description covers purpose, selector semantics, and the freshness/negative-result caveats. Only connection_context and the relationship to sibling lookup tools are left 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 0%, so the description carries the full burden. It documents the four selector parameters (business_id, ad_account_id, page_id, fb_user_label) and, crucially, the mutual-exclusivity rule that the schema cannot express. It omits connection_context, which is the only unexplained parameter.

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: 'Read cached BM links.' It is distinguishable from list-type siblings like assets_list_businesses and assets_list_pages. The 'BM' abbreviation is jargon, but the resource is otherwise clear.

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 strong invocation guidance ('Choose exactly one' of the four selectors, 'never combine an asset ID with an FB user'), which mostly belongs to parameter semantics. It never says when to prefer this tool over sibling lookups such as assets_pick or assets_list_businesses, so the when/when-not guidance is implied at best.

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, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds the word 'cached', which hints the selection comes from previously listed assets, but does not explain cache staleness, whether the pick is persisted, or how it relates to the connection_context parameter.

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 nine-word sentence, front-loaded with the verb and the three options. No waste, but underspecified rather than tight.

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, but with 0% parameter coverage, no usage routing against ~90 siblings, and only 'cached' to convey behavior, the description is too thin for a tool that gates access to the three core asset types.

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 carries the full parameter burden, yet it only implies that 'kind' selects among the three asset types and says nothing about 'search', 'ad_account_id', or 'connection_context'. For a 4-param tool with an opaque mctx_v1_ pattern, this is a real 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?

Specific verb 'Choose' with three concrete resource types (ad account, Page, Instagram account). Clear what it does, but 'cached' is the only qualifier and it doesn't distinguish itself from siblings like accounts_list_eligible_pages or assets_list_pages, which also surface similar entities.

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?

No when-to-use guidance, no mention of alternatives, no criteria for selecting one of the three kinds. The agent must infer that this is a picker for an existing cache versus the search/list siblings, and nothing in the description says so.

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=false, and openWorldHint=true, so the safety profile is covered. The description adds only the scope of the refresh (account plus Page cache) and says nothing about whether this is async, how expensive the external fetch is, or whether repeated calls are idempotent. With annotations carrying the safety burden, a 2 reflects minimal added behavioral value.

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 short, front-loaded sentence with no wasted words. It is efficient, though it is terse to the point of under-specification rather than being maximally informative.

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. However, for a non-read-only, open-world tool with three undocumented parameters and no sibling routing, the description leaves the agent without enough to call it correctly in context.

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% across three parameters, and the description compensates for none of them. 'Account' loosely maps to ad_account_id and 'Page cache' hints at page_id, but connection_context (with its mctx_v1_ pattern) is entirely unexplained, so the caller gets no help on required formats or optional-parameter effects.

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 (refresh) and resource (one ad account) plus the side effect on the connection Page cache. It implicitly distinguishes itself from assets_refresh_all by scoping to 'one account', but it never names that sibling, so an agent must infer the distinction from the 'one' qualifier alone.

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 guidance on when to use this versus assets_refresh_all, assets_list_ad_accounts, or any of the other assets_* tools. No prerequisites (e.g. an established connection context) or rate/latency expectations are 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 readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The word "Queue" usefully signals asynchronous, fire-and-forget behavior that the annotations do not convey, but the description omits cost, throttling, scope of the refresh, and how to observe completion — real gaps for a mutation 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?

A single front-loaded sentence with no filler — nothing redundant is present. The terseness is under-specification rather than bloat, so it scores well for structure while leaving content gaps.

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?

The output schema removes the need to document return values, and annotations cover safety. However, for a write operation that refreshes assets in bulk, the description omits what gets refreshed, whether the action affects every linked account, and any async/status-checking context — leaving the agent unable to reason about consequences or follow-up steps.

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% for the single connection_context parameter, and the description supplies no meaning for it at all. Since coverage is well under 50%, the description was expected to compensate and does not; only the opaque pattern in the schema hints at its nature.

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?

"Queue an asset snapshot refresh" names a verb (queue/refresh) and a resource (asset snapshot), so the operation is identifiable. But it never clarifies the scope implied by "all" in the name, nor distinguishes it from the sibling assets_refresh_ad_account, so an agent cannot tell the two apart from the text alone.

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 statement of prerequisites, and no routing to alternatives. The sibling assets_refresh_ad_account exists as an obvious narrower variant, and the description says nothing about when to prefer one over the other.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds the scoping fact that only the caller's assets are searched, which is useful, but says nothing about result limits, ranking, or pagination.

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?

One front-loaded sentence with no filler; the purpose and scope are conveyed in a single clause with zero wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need no explanation, and annotations cover safety. However, the description leaves open what happens when the optional 'query' is omitted and how the mention search is scoped to results, which matters for a tool with zero required parameters.

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 single 'query' parameter has 0% schema description coverage and the description never mentions it, so an agent gets no help on what the query string matches or how maxLength=100 interacts with it. With one undocumented parameter, the description does not 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 specific verb ('Search') and enumerates the resource domains ('ad accounts, products and campaigns') plus the scope ('composer @-mentions'). An agent can distinguish it from siblings like assets_list_ad_accounts or assets_pick, 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 phrase 'composer @-mentions' implies the context of use (autocomplete while composing), but there is no explicit when-to-use, no exclusions, and no pointer to any alternative search tool. Usage is inferred 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, destructiveHint=true, and openWorldHint=false, so the mutation/risk profile is covered structurally. The description adds no behavioral context beyond that – it doesn't say what toggling these flags actually does, whether the change is reversible, or what permissions are required.

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 terse sentence with the verb and the affected fields front-loaded; nothing is wasted. It is efficient, though the extreme brevity is what creates the informational gaps elsewhere.

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, permission-altering mutation with a 0%-documented schema, the description is too thin. An output schema exists so return values need not be explained, but the agent still lacks any sense of the effect or scope of these flag changes.

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% across 5 parameters, so the description must carry the burden. It names three of the five parameters but provides no meaning for any of them (e.g. what allow_decision routing controls), and leaves ad_account_id and connection_context entirely unaddressed.

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 ('Update') and resource ('routing flags'), and names the three flags it toggles (allow_create, allow_pull, allow_decision). It does not distinguish itself from related siblings like fb_users_update_permissions or fb_users_refresh_routing, so an agent could confuse the scope.

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?

No guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. The presence of multiple similarly-named permission/routing tools (fb_users_update_permissions, fb_users_refresh_routing) makes this absence more costly.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered by structured data. The description adds a genuinely useful behavioral fact not present elsewhere: the call is currently free during the public beta. It says nothing about rate limits, caching, or what happens for meters with no data.

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; the core purpose leads and the beta note trails. It is efficiently sized, though its brevity leaves the parameter and usage burden unaddressed elsewhere.

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, but with four parameters at zero description coverage and no usage guidance, an agent cannot determine how to scope a usage query. For a query tool with optional-but-meaningful dimensions, the definition is under-specified.

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?

All four parameters (meter, period, channel, connection_context) have 0% schema description coverage, so the description carries the full burden and fails to name or explain any of them. 'Plan and measured usage' loosely hints at meter/period but gives no accepted values, formats, or defaults for optional params. This is a clear gap given 4 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?

The description pairs a specific verb ('Read') with specific resources ('plan and measured usage'), so an agent can tell this is a read-only billing/usage inspection tool. There are no sibling billing_* tools to differentiate from, so no sibling-routing language is expected. The parenthetical about the beta is pricing context rather than purpose, but the core statement 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?

Nothing states when to call this versus other read tools, nor what the meter/period/channel dimensions are for. The 'free during the public beta' note is commercial context, not usage guidance. An agent must infer the triggering scenario entirely.

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 only give readOnlyHint=false, destructiveHint=false and openWorldHint=true. The description adds genuinely new behavior: it reads current Meta settings, writes an approval draft, returns approval_ref and plan_digest, and critically 'This call does not change delivery' — the two-phase prepare/confirm contract that the annotations do not 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?

Four short sentences, front-loaded with what the tool does, then the return keys, then the safety note, then the alternative. No filler; every clause carries routing or safety 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?

Output schema exists so return values need not be detailed, and the description still names the key returned fields consistently. The workflow, non-effect, and next step are covered; the only real gap is parameter-level detail for an opaque connection_context and daily_budget format.

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% for 4 parameters, so the description carries the burden. It only implies campaign_id, daily_budget and ad_account_id through prose and says nothing about the daily_budget number format, ad_account_id semantics, or the connection_context token pattern — the least obvious parameter is entirely 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?

States a specific verb, resource and scope: 'Prepare one campaign daily-budget change'. The word 'one' implicitly separates it from the batch sibling campaigns_prepare_budget_changes, and 'campaign' separates it from adsets_prepare_budget_change. An agent can identify the target operation without opening the 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 names the follow-up tool ('apply only after approval with operations_confirm_campaign_budget') and the alternative for a different case ('Prefer entities_prepare_update for new work'). The when, the when-not, and the workflow ordering are all 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 non-destructive and open-world, and the description adds meaningful context: it reads current Meta budgets, persists one approval draft, returns approval_ref/plan_digest, and explicitly says 'this call does not change delivery' so the agent understands nothing goes live yet. It stops short of noting auth/permission requirements or draft lifetime.

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 tight sentences, front-loaded with the action and scope, followed by return values, the confirm path, and the alternative. 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 mutation-prep tool with an output schema covering return values and annotations covering safety, the description supplies the missing workflow context (prepare vs. confirm, no delivery impact). Only peripheral details such as auth scope and draft expiry 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?

Reported schema description coverage is 0% at the top level, so the description carries the burden; it conveys the 1-10 item bound and that each entry is a campaign daily-budget change, but connection_context is unexplained in both description and schema. Nested field semantics (currency units, IDs from read results) live only in the schema payload.

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 (Prepare), resource (campaign daily-budget changes), and scope (1-10), and explicitly contrasts itself with both the confirm step (operations_confirm_campaign_budgets) and the generic entities_prepare_update sibling. An agent can distinguish it from campaigns_prepare_budget_change and the confirm family 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?

Gives a clear two-phase workflow: draft now, then apply only after approval via operations_confirm_campaign_budgets. It names an alternative (entities_prepare_update), though the selecting condition ('for new work') is vaguely worded and doesn't spell out when NOT to use 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 declare readOnlyHint=false and destructiveHint=false, and the description adds the crucial clarification that this call does not change delivery – i.e. it writes a draft rather than mutating the account. It also names the artifacts returned (approval_ref, plan_digest) and the required authorized-account context.

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 the action and outcome, followed by the approval handoff and the routing hint in three tight sentences. The trailing fragment "Prefer entities_prepare_update for new work" is terse to the point of being slightly ambiguous, but nothing is wasted.

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?

The approval workflow, non-delivery guarantee, and downstream tool are all covered, and an output schema exists so return values need no prose. The gap is the undocumented parameter set, which leaves the agent guessing on connection_context and status value semantics.

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% across 4 parameters, so the schema supplies names and types but no meaning. The description adds nothing about campaign_id, ad_account_id, connection_context, or which values target_configured_status accepts, so the low-coverage burden is not met.

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?

Specific verb+resource ("Prepare one campaign status change") plus the two-step workflow it belongs to (read settings, save approval draft). It explicitly distinguishes itself from operations_confirm_campaign_status and entities_prepare_update, so an agent can route 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?

Explicit that the change is applied only after approval via operations_confirm_campaign_status, and it redirects new work to entities_prepare_update. It doesn't disambiguate against the parallel adsets_prepare_status_change / ads_prepare_status_change siblings, but the when-to-use context 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?

Annotations declare readOnlyHint=false and destructiveHint=false, so the description's job is to add context. It discloses the important behavioral trait that this only builds a draft requiring approval before launch_confirm executes, and that the original link_id should be reused when exposed. It does not cover collision handling, idempotency, or failure behavior for such a large mutation, so not a 5.

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 compact sentences, front-loaded with the action and scope before the alternative and the approval flow. There is one run-on with a missing break ("...after approval Use the workflow's original link_id...") that slightly harms readability, 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?

An output schema exists so return values need not be described, and the safety profile is in annotations. For a tool with a very large nested schema (~30 request fields, multiple policies and modes), the high-level workflow guidance leaves gaps around append-mode semantics, target ID selection, and collision/partial policies. Adequate, but thin relative to 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?

Schema description coverage is 0% at the parameter level, so the description must compensate. It names the most load-bearing fields (request.ad_account_id, template_name, creative_source) and tells the agent to set append_mode and target IDs explicitly, but does not explain the three append_mode values, the target_campaign_id/target_adset_id pairing, or the policy enums. Adding to the schema's own enum descriptions, this is minimally sufficient rather than rich.

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 (prepare new ads / append to campaign or ad set) and names the sibling it is not for (copy_ad_quick_copy). The core inputs it relies on (ad_account_id, a saved template, one creative_source) are called out. It does not distinguish itself from the many other *_prepare tools in the sibling list, 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?

Gives clear context: it is for new ads or appending, live-ad copies should route to copy_ad_quick_copy, and the draft must be reviewed and executed via launch_confirm. Missing explicit when-not conditions (e.g. versus campaigns_recreate_from_task or copy_ad_clone_structure), but the selection signal for the closest sibling 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered, and 'reconcile' is consistent with a read/compute operation (no contradiction). However, the description adds nothing beyond them: no indication of what is reconciled, whether a plan is persisted, or what the reconciliation produces.

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?

It is a single short fragment with no waste, but under-specification masquerading as conciseness. Nothing is front-loaded that would orient the agent before it reads the 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?

For a tool with a deeply nested request object, zero schema descriptions, and enum-like decisions (scope_policy strict/partial), this one-line fragment is far too thin. The output schema means return values needn't be explained, but purpose, sequencing vs. prepare siblings, and parameter intent are all 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 description coverage is 0% across two top-level parameters, and the nested request object exposes seven properties (ad_account_id, target_campaign_id, requested_items, requested_budget_minor, scope_policy, currency) with no in-schema docs. The description mentions none of these, leaving parameter meaning entirely opaque.

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 largely restates the tool name ('Reconcile ... campaign plans') and adds only the opaque modifiers 'fixed existing-Ad' and 'before prepare'. An agent cannot tell what reconciliation actually means operationally, nor how it differs from the numerous campaigns_prepare_* 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?

'before prepare' is the only usage signal, and it references a phase, not a sibling tool (no 'prepare' tool exists by that name; the siblings are campaigns_prepare_budget_change, campaigns_prepare_status_change, etc.). No conditions, prerequisites, or alternatives are 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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description's 'Prepare' wording hints at a two-phase prepare/confirm workflow, but it does not state that confirmation is required, what state is created, or what the operation affects.

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?

It is short, but the first sentence is a run-on with a missing period before 'Use' ('...prior create task Use the workflow's...'), which harms readability. Brevity here reflects under-specification rather than tight editing.

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 three-parameter mutation tool with an output schema but 0% parameter description coverage, the description is far too thin. It omits what task_ref accepts, the meaning of failed_items_only, and the required connection_context format, leaving an agent unable to invoke it confidently.

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 explains none of the three parameters (task_ref, failed_items_only, connection_context). Worse, it references 'link_id,' which is not a parameter in the schema at all, adding confusion rather than clarity.

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 'recreate from a prior create task,' which names an action and a source, but it largely restates the tool name (campaigns_recreate_from_task) rather than clarifying what 'recreate' produces. It does not clearly distinguish this from siblings like campaigns_quick_create or copy_ad_clone_structure.

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 reference to the confirm step (operations_confirm_campaign_recreate) or alternative recreate paths. The only directive, 'Use the workflow's original link_id when exposed,' is a data hint, not tool-selection guidance.

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/openWorldHint=false/destructiveHint=false and the description is consistent with them. It adds real behavioral context beyond the annotations: the return is a status/channel or not_found_or_expired, the link should be reused while valid, and polling is discouraged. It does not, however, describe expiry timing or failure modes.

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 tightly packed clauses with the action and handle formats front-loaded, then the return values, then the routing hint. Every phrase carries usable information; 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?

An output schema exists, so return values need not be detailed, and the safety profile is covered by annotations. What is missing is any explanation of the second parameter, connection_context, but otherwise an agent has enough to call this correctly.

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 carries the burden: it explains that intent_id accepts ci_*, Meta connect_id, or fbconn_live_* handle formats, which is meaningful beyond the bare 'string' type. However connection_context (pattern ^mctx_v1_[0-9a-f]{64}$) is never mentioned, leaving half the parameters undocumented.

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 (Check) plus the exact resource (one existing authorization handle) and constrains scope to a single handle rather than a batch. It also names the sibling it is not (setup_check_channel_connect), so an agent can route without opening either 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?

Explicit timing ('after the user finishes'), an explicit exclusion ('do not start automatic polling'), guidance to reuse the link while valid, and a named alternative for setup connect_ids. Nothing 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?

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true), so the bar is lower. The description adds genuinely new behavioral context: the link is single-use and must be completed by a human, and the call yields connect_url rather than completing a connection.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no filler, with the core action and its return value front-loaded and the alternative routing clause placed second.

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 details need no prose, and the annotations carry the safety profile. The main residual gap is the unexplained connection_context parameter, but the description is otherwise sufficient 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 0%, so the description must carry parameter meaning. It does supply the accepted channel values (meta|google_ads|tiktok) and the mode value (add_connection), which the schema lacks as enums, but connection_context is left entirely 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?

States a specific verb and resource ('Create a single-use browser authorization link'), scopes it to explicit channel values and a mode, and names the return value connect_url. It is clearly distinguishable from siblings like setup_begin_channel_connect and connections_check_intent.

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: 'Prefer setup_begin_channel_connect when you need its explicit connect_id/check workflow.' It gives a clear selection criterion against the most likely alternative but does not state when this tool is preferred over connections_check_intent or explain 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?

Annotations already declare readOnlyHint, openWorldHint=false, and destructiveHint=false, so the safety profile is clear. The description adds that this is a guide with a link and steps rather than an automated disconnect, which is useful context, but it does not cover auth requirements, rate limits, or other behavioral traits.

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 concise phrase with no wasted words. It is front-loaded with the main content type, though it is a fragment rather than a structured 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?

An output schema exists, so return values need not be explained, and annotations cover the safety profile. However, the input parameter remains undocumented in both the description and schema, which leaves a notable gap for an agent that might need to pass connection_context.

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 schema has a single optional parameter, connection_context, with 0% description coverage, and the tool description does not mention it at all. The description therefore fails to compensate for the missing schema documentation, leaving the parameter's meaning and format entirely 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?

The description says it provides a Facebook link and steps for removing AdsAgent's access, which conveys the resource and intent, but it lacks an explicit action verb and does not differentiate itself from sibling connections_* tools such as connections_list or connections_create_intent.

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 the user to remove AdsAgent's access' implies the use case, but there is no explicit comparison to alternatives or guidance on when not to use this tool versus other disconnect-related or connection-listing 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description's one contribution is 'redacted', which usefully warns that returned connection data is masked — a trait annotations do not express. It says nothing about pagination or result volume, so the gain is modest.

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?

It is a single front-loaded phrase with no padding, which is structurally clean. But the brevity comes from omission rather than discipline — it is under-specified for a four-parameter, paginated listing tool.

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 explanation is not required, and annotations cover safety. Still, with four undocumented parameters, no pagination behavior, and no routing relative to the other connections_* tools, the description leaves the agent short of what it needs to invoke this correctly.

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% across four parameters (limit, cursor, channel, connection_context), and the description compensates for none of them. It gives no hint about what 'channel' filters, how 'cursor' paginates, or what the mctx_v1_ pattern identifier represents, so the agent must guess at invocation semantics.

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

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

It gives a verb ('List') and a resource ('redacted platform connections'), and the qualifier 'redacted' tells the agent the payload is masked. However, it does not distinguish this from siblings such as connections_check_intent, connections_create_intent, or connections_disconnect_guide, leaving the agent to infer which of the connections_* family it wants.

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 tools in the connections_* family. The agent gets no signal about whether this is a discovery step before connections_create_intent or an independent listing operation.

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

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

Annotations declare readOnlyHint=false with destructiveHint=false, implying a non-destructive write (likely creating an export artifact), but the description never reconciles 'Export ... as CSV' with that. It omits the confirm_export confirmation step, whether a file is created or returned inline, and any rate/quota behavior — all things annotations do not cover.

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, which is structurally clean. However, at seven words it is undersized for a 10-parameter tool with four required fields and a confirmation flag, so conciseness is achieved at the cost of adequacy.

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, but the description leaves everything else uncovered: required scope shape, date/attribution/grouping semantics, and the confirm_export two-step behavior. For a tool this complex, the definition is materially incomplete.

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% across 10 parameters, including a required discriminated 'scope' object and required group_by/date_from/date_to. The description mentions none of them, so an agent gets zero guidance on defaults, the date format, grouping granularity, or the confirm_export flag.

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+format: export stored Console metrics as CSV. Clear enough that an agent knows what it produces, but it does no sibling differentiation against the very similarly named insights_export_csv or console_query_overview, which an agent would plausibly confuse it with.

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?

No indication of when to use this over insights_export_csv (also a CSV export) or console_query_overview, and no prerequisites such as connection setup or confirm_export flow. Usage context is left entirely to inference 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?

Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond that baseline: it does not mention whether the result is paginated (a result_cursor parameter exists), whether an ad account is required for scoping, or any rate-limit 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?

It is a single front-loaded sentence with no wasted words, which is structurally clean. The problem is under-specification rather than verbosity, so it neither earns praise nor commits a conciseness violation.

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. Still, for a five-parameter read tool with an opaque purpose ('evidence') and zero schema coverage, the description leaves too much unsaid — no scoping rules, no pagination note, and no differentiation from overlapping console tools.

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% across five parameters, so the description carries the full burden of explaining entity_type, entity_ids, ad_account_id, result_cursor, and connection_context. It mentions none of them, leaving the agent with no guidance on enum values, ID format, pagination, or connection scoping.

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 verb ('Read') and a resource ('stored entity configuration evidence'), so the general shape of the operation is clear. However, 'evidence' is unexplained jargon, and it does not distinguish itself from siblings like console_query_overview or console_export_csv. An agent knows it is reading something but not what makes this tool distinct.

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 reference to any alternative. The agent is left to infer that this should be called when configuration evidence is needed, but nothing in the text tells it when this is preferred over the other console_* 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?

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=true. The phrase "for approval" adds genuine context not present in the annotations — this stages a change rather than applying it — but nothing is said about validation, whether the staged change expires, idempotency, or what the approval handoff requires.

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?

Single front-loaded sentence with zero filler, which is structurally sound. However, for a 7-parameter, 5-required tool that overlaps heavily with named siblings, seven words is under-specification rather than effective concision.

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 that is the only mitigating factor. With 0% schema description coverage, 7 parameters, a required-field set of 5, and numerous overlapping prepare siblings, the description leaves an agent without enough information to call this tool correctly.

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% across 7 parameters, and the description supplies no parameter meaning at all. Nothing explains the enum pairings, the entity_id/ad_account_id formats, or the role of expected_current (apparently an optimistic-concurrency guard) or connection_context, so the description does not compensate for the documentation void.

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?

"Prepare a Console delivery change for approval" gives a verb (prepare) and a broad resource (Console delivery change), but never states the scope it actually covers — entity_type campaign/adset/ad and action budget/bid/status — which is exactly what distinguishes it from the many sibling prepare tools. An agent cannot tell from the text whether this is the generic path or a specialized 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?

No when-to-use, when-not-to-use, or alternative routing is given. With siblings like adsets_prepare_budget_change, adsets_prepare_bid_change, campaigns_prepare_status_change and products_delivery_pause_prepare present, the absence of any selection guidance is a real gap.

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