Meta Ads (Facebook & Instagram)

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

Annotations already provide idempotentHint and non-destructive, but the description adds meaningful context: configuration yields a permanent non-expiring connection, while pasting a token is session-only. Depth is good though it does not explain all error/edge-case behavior.

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

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

Two sentences carry a lot of useful information without significant waste. The wording 'log in in the browser' is slightly awkward and the first phrase could be cleaner, but everything included is relevant to an agent.

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

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

For a simple optional-parameter auth tool, the description covers both invocation styles and configuration options. It omits what a successful token response returns, but there is no output schema and the overall flow is reasonably complete for decisive agent use.

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 only names the optional token with no description, but the tool description thoroughly explains that token is a JWT pasted by the user and that omitting it obtains the login link. This fully compensates for the 0% schema description coverage.

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

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

The description clearly identifies the tool's purpose: authenticating an MCP.AI server for IDE agents by either returning a login link or accepting a pasted token. It is concrete and distinguishes itself from the ADS-related siblings, despite the separate 'connect' tool.

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 explicitly recommends the best-practice configuration method (permanent header), explains when to call with a pasted token for session-only login, and specifies calling with no args to get a link. This gives an agent actionable guidance on when and how to use the 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?

Beyond the annotations (readOnly, idempotent, non-destructive), the description reveals concrete output behavior: authenticated flag, empty pending array, and URL generation when credentials are required. This is valuable and not duplicate 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?

The description is two efficient, front-loaded sentences. The purpose is given first, and each sentence adds meaningful behavioral detail without wasted wording.

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

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

For a parameterless status-checking tool with no output schema, this description captures the main result states and the relevant URLs well. It is sufficient for the agent to understand the expected outcome.

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

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

The tool has zero parameters and the schema documents that cleanly. Baseline for no-param tools is 4, and no additional parameter explanation is needed in the 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?

The description clearly states the tool returns connection status and URLs, providing a specific verb + resource outcome. It also differentiates connect from authenticator by framing it as a read-only status check.

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 conditional context ('When all providers are connected...', 'When credentials are missing...') makes it clear when this tool provides useful status information. It does not explicitly name alternatives or say when not to use it.

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?

Beyond annotations (readOnlyHint=false, openWorldHint=true), the description discloses critical behaviors: invoke works without installation, requires no toolkit bloating; auth/payment needs return connect/checkout links; writes require workspace owner/admin; search/describe flag installed status. It also clarifies that invoke is one-off, effectively addressing non-idempotency implicit in annotations. No contradiction.

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 dense paragraph, not structured with bullets or sections, making it harder to scan. It packs a lot of necessary information but could be broken down for readability. However, every sentence adds value; it's not padded. The lack of structure reduces conciseness and 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?

Given the tool's complexity (23 params, many actions, no output schema), the description covers a lot: core flow, one-off execution, auth/payment handling, permission requirements, and the prompt library. It misses explicit return-value descriptions for search/describe, but it does mention installed-status flags and link returns for invoke. It's largely complete but could benefit from stating search result format or error scenarios.

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 adds substantial meaning by explaining the key action values (search, describe, invoke, install, etc.) and the flow that references parameters like tool_id and arguments. It doesn't detail all 23 parameters, but it compensates for the most important ones. Some parameters (limit, query, prompt_*) remain unexplained, but the high-level operational semantics are clear.

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 clearly states the tool's role as the official marketplace and execution gateway for MCPs, explaining the core flow (search → describe → invoke) and distinguishing it from sibling tools (which are specific Meta Ads operations). It names the resource (marketplace) and its dual purpose (catalog and runner), making it 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 provides explicit guidance on when to use invoke vs install ('prefer invoke for a single/occasional use'), when install is appropriate (to make permanent), and explains the search/describe flow. It also clarifies the prompt library usage and when to use request_mcp or report_bug. This is excellent alternative-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=true, destructiveHint=false, and idempotentHint=true, covering safety. The description adds that it includes creatives and performance metrics, which is useful context, but does not elaborate on pagination, filtering behavior, or auth requirements. Since annotations cover the safety profile, 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?

The description is a single, compact sentence that efficiently conveys the core purpose and key data points. It contains no redundant words, earning a high conciseness score, though it could be slightly more structured with a list of metrics, but it is still well within acceptable bounds.

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 5 optional parameters and no output schema, the description is incomplete. It mentions some return metrics but fails to explain parameter semantics, default behaviors (e.g., include_paused=false), or how to scope the query (since/until). The single sentence is too sparse to fully guide an agent, especially given the lack of 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%, and the description provides zero information about the parameters (since, until, account, auth_account, include_paused). It fails to explain their meaning or usage, leaving the agent without guidance. With no coverage and no compensation, this is a critical 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 clearly states it lists ads with creatives and performance insights, using the specific verb 'List' and resource 'ads'. It mentions specific content (image, video, copy) and metrics (spend, revenue, ROAS, actions), distinguishing it from sibling tools like meta_ads_campaigns or meta_ads_adset_detail.

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 it is for listing ads, but provides no explicit guidance on when to use this tool over alternatives such as meta_ads_realtime or meta_ads_roas, nor any exclusions. It could benefit from mentioning scenarios where other tools are more appropriate, but the basic context is implied.

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

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

The annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds 'Permanently delete' and 'Irreversible,' reinforcing the permanence beyond a simple destructive flag. It also mentions bulk support, which is not captured in annotations. No contradictions are present. The description covers key behavioral traits adequately given the 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?

The description is extremely concise: two short sentences, front-loaded with the primary purpose. It wastes no words and efficiently conveys the core action, irreversibility, and bulk capability. This is a model of terseness 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?

The tool is a simple delete operation with no output schema. The description covers the essential aspects: permanent deletion, irreversibility, and bulk option. It lacks details on error handling or side effects (e.g., impact on associated ads), but given the simplicity and annotations, this is acceptable. The only notable gap is the lack of parameter usage details, but that is already penalized in parameter 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%, so the description must compensate. It only mentions 'accepts adset_ids for batched execution,' which partially explains the adset_ids parameter but does not clarify the relationship between adset_id and adset_ids (e.g., whether both can be used, precedence) nor explain auth_account. The description adds minimal semantic value beyond the raw schema, leaving ambiguity about the required adset_id and optional batch usage.

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 clearly states the operation: 'Permanently delete a Meta Ads ad set.' It specifies the resource (ad set) and the action (delete), with the added qualifier 'permanently' and 'irreversible' to emphasize the destructive nature. This distinguishes it from sibling tools like update or create, and also from deletion of other resources (e.g., campaigns, audiences).

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 usage for permanently removing an ad set, but does not explicitly contrast with alternatives like pausing or deactivating via update tools. It does not mention when not to use this tool (e.g., if the goal is temporary deactivation). While the name and destructive nature make the primary use case clear, the lack of explicit guidance relative to other operations prevents a higher score.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds no extra behavioral context beyond listing which fields are returned, and there is no contradiction with the 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?

The description is a single, front-loaded sentence immediately stating the action and resource, followed by a short contextual second sentence. No filler or repetition; every word contributes to the tool's core purpose.

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 description tells the user what data will be returned, but with no output schema and only 0% parameter documentation, it leaves major gaps around which account to use, what 'authentication' means, and how include_paused behaves. The read-only nature is covered by annotations, but the actual parameter usage is left largely unexplained.

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

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

Schema description coverage is 0% yet the description does not clarify the meaning or purpose of the three parameters (account, auth_account, include_paused). The description only lists output fields, not input semantics, so the agent gets no guidance on how to set parameters correctly.

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 clearly states a specific verb ('Get') and resource ('detailed adset info') and enumerates the attributes included (targeting, budget, schedule, billing, optimization goal, delivery status). The phrase 'Fills the gap between campaigns and ads' positions it distinctly among sibling tools like meta_ads_campaigns and meta_ads_ads.

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 'gap between campaigns and ads' phrase implies this tool is used when campaign-level or ad-level detail is insufficient, providing some context. However, it does not explicitly state when to use this tool over alternatives, nor does it provide exclusions or mention related tools by 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=false, destructiveHint=false, idempotentHint=false, so the description need not repeat these. The description adds valuable context on failure modes (budget requirements, optimization_goal matching, promoted_object requirements), which is beyond annotations. However, it doesn't disclose the return format or what happens on invalid input, which is acceptable given the detailed usage rules.

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 multi-paragraph but front-loads the core action and follows with actionable bullet points. Each sentence adds value, such as 'Budgets in cents' and the budget requirement. It is not overly verbose given the complexity, though it could be more structured with clear sections.

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

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

Given the tool's complexity (19 parameters, 0% schema coverage, no output schema, no annotations), the description does an excellent job covering the most challenging aspects: budget constraints, optimization_goal compatibility, and promoted_object requirements. It also mentions bulk support and the flattened action. It does not cover all parameters but focuses on the ones likely to cause errors, which is sufficient for a competent agent.

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

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

Schema description coverage is 0%, so the description must compensate for 19 parameters. It provides detailed semantics for targeting (JSON structure), budgets (in cents, requirements), optimization_goal (specific mappings), promoted_object (format for pixel and page), and destination_type (only for non-website). However, not all parameters (e.g., bid_amount, bid_strategy, status, start_time) are explained, but the description covers the most critical ones.

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 explicitly states 'Create or update Meta Ads ad sets' with a detailed list of actions (create, update) and resources (campaign, targeting, budget, schedule). It clearly distinguishes itself from siblings like meta_ads_adset_delete and meta_ads_adset_write_update by naming the destructive delete operation and noting that update is covered here.

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 explicit when-to-use guidance, such as the critical rule about budgets: 'the ad set REQUIRES daily_budget or lifetime_budget, UNLESS the parent campaign already carries the budget' and when to omit budget. It also states when NOT to use this tool ('For destructive delete use meta_ads_adset_delete') and provides conditional requirements for optimization_goal and destination_type.

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 are minimal (all false/no hints), so the description carries the burden. It discloses significant behavioral constraints: budget requirement and CBO exception, lifetime_budget requiring end_time, optimization_goal-to-campaign-objective mappings, promoted_object requirements for specific goals, and destination_type restrictions. This goes well beyond the structured fields, giving agents necessary failure-avoidance 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?

The description is dense and well-organized with action bullets, a prominent BUDGET warning, and code-like examples. It is longer than the ideal 2-sentence description, but the complexity of the tool (19 params, multiple conditional rules) justifies the length; no filler sentences are present.

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 19-parameter create/update tool with no output schema and uninformative annotations, the description covers the most failure-prone areas (budget, optimization goal, promoted_object, destination_type) and bulk support. It doesn't describe return values or auth_account usage, but given no output schema and the exhaustive field-level rules provided, it is substantially complete.

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

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

Schema coverage is 0%, but the description injects semantics for the highest-risk parameters: targeting JSON format, budgets in cents, optimization_goal allowed values per objective, promoted_object structure, and destination_type applicability. Many remaining params (name, status, bid_strategy, billing_event) are either self-explanatory or constrained by enums, yet the description does not explicitly annotate all 19, so it's helpful but not exhaustive.

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 opening line 'Create or update Meta Ads ad sets' is a specific verb+resource statement. It enumerates actions (create linked to a campaign, update existing ad set) and explicitly points to meta_ads_adset_delete for destructive deletions, distinguishing from that sibling. The range of covered fields (targeting, budget, schedule) makes the scope 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?

The description gives explicit alternative for delete ('For destructive delete use meta_ads_adset_delete') and provides field-level when-to-use guidance (e.g., destination_type only for non-website destinations, omit for website traffic; budget rules depending on campaign budget optimization). It does not explicitly contrast with meta_ads_adset_write_create, but the combined create/update nature and clear action list imply the context.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which cover the safety profile. The description adds no extra behavioral context beyond restating the listing action; it does not mention pagination, rate limits, or data scope, but it is consistent with the 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?

The description is a single, concise sentence that gets straight to the point. It contains no redundant or extra content, and the information is front-loaded. This is ideal for a simple list operation.

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

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

Given the lack of output schema, the description should at least clarify the return format or any important limits. It does not address parameter usage, authentication requirements, or result scoping. The tool is part of a large sibling set, and without additional context, the agent may not know how 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?

The input schema lists 'account' and 'auth_account' with no description in the schema or the tool description (schema coverage 0%). The description mentions 'ad account' but does not explicitly link it to the 'account' parameter, and 'auth_account' is completely unexplained. No parameter meaning is added beyond the raw names.

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 clearly states the action ('List') and the resource ('Custom Audiences in the ad account'), making the purpose unambiguous. It is specific enough to differentiate from tools like meta_ads_campaigns or meta_ads_audience_delete, though it does not explicitly name alternatives.

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

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

No guidance is provided on when to use this tool versus alternatives such as meta_ads_audience_write_create or meta_ads_audience_delete. The description simply states the operation without context on prerequisites, intended scenarios, or when to prefer other audience 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 destructiveHint=true, and the description adds 'Permanently' and 'Irreversible' which reinforces the destructive nature but adds little new info. However, it does disclose the bulk deletion capability, which is a behavioral trait not evident from annotations. It omits details about auth requirements or failure modes, but for a delete operation, the core behavior is clear.

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 extremely concise—two sentences containing only essential information: what the tool does and its bulk capability. There is zero fluff or redundant wording. Every word adds value, and the structure front-loads the primary purpose.

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 operation with 3 parameters and no output schema, the description covers the core action and bulk mode but omits critical context: prerequisites (e.g., authentication requirements), behavior on failure, and the role of the required auth_account parameter. While the simplicity of deletion mitigates the need for extensive documentation, the lack of any parameter semantics for auth_account and no mention of return behavior leaves 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 compensate. It mentions `audience_id` implicitly via the action and explicitly states `audience_ids` for bulk execution, but it does not explain `auth_account` at all. The distinction between single and bulk is useful but incomplete—no details on parameter formats, constraints, or relationships. With 3 parameters and only one partially explained, the description falls short.

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 clearly states the action: 'Permanently delete a Custom Audience.' This is a specific verb+resource combination that distinguishes it from sibling delete tools for adsets, campaigns, and creatives. It unambiguously identifies the target resource and the irreversible nature of the operation.

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 usage by naming the exact action, but does not explicitly state when to use this tool versus alternatives or mention any prerequisites. The bulk support note ('accepts audience_ids for batched execution') provides usage context for deleting multiple audiences at once, but there's no when-not-to-use guidance or references to sibling 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?

The description reveals important behaviors beyond annotations: PII is SHA-256 hashed before upload and data is normalized and hashed automatically. It also notes bulk execution capability. These add meaningful context not present in the annotations, though auth requirements and failure behavior remain undisclosed.

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 relatively compact and organized with an actions list, data format, and pointers to alternatives. The create action bullet and the '[Flattened action: add_users]' note add minor noise, but overall the description is efficient and front-loaded.

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 description covers the core operation, user data format, hashing, bulk support, and delete alternative, which is helpful. However, it lacks outcome/return behavior, required parameter clarification, and guidance on account/auth selection, making it only partially complete for a 7-parameter mutation tool with no output schema.

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

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

Schema description coverage is 0%, so the description must compensate. It defines the users array shape (email, phone?, fn?, ln?) and mentions audience_ids for batch, which is helpful. However, it does not explain other parameters such as account, auth_account, audience_id singular, name, or description, leaving significant gaps in parameter understanding.

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 clearly identifies the add_users action as uploading hashed user data, specifying PII fields and hashing behavior. It also explicitly distinguishes from the destructive delete tool, though the inclusion of a create action and the '[Flattened action: add_users]' note adds slight ambiguity.

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 an explicit when-not to use this tool ('For destructive delete use meta_ads_audience_delete') and mentions bulk support via audience_ids, which signals batch usage. However, it does not contrast with meta_ads_audience_write_create or other write-oriented sibling tools, so guidance is partial.

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 discloses that PII is SHA-256 hashed and normalized automatically, and mentions bulk support via audience_ids. It also clarifies that destructive actions are in a separate tool, aligning with destructiveHint=false. These details add meaningful behavioral context beyond the 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?

The description is verbose and includes both create and add_users actions before clarifying it is flattened to create. The structure could be more concise and front-loaded with the specific action. The bulk support statement adds a separate concern, making the text somewhat unfocused.

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

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

Given no output schema, the description should explain return values or success indicators, but it does not. It lacks details on required parameters (though none are marked required), authentication prerequisites, and error handling. It covers user data normalization and bulk support but remains incomplete for a transactional create operation.

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

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

Schema coverage is 0%, so the description must compensate. It explains the users format (array of {email, phone?, fn?, ln?}) and audience_ids for bulk execution, but it does not describe name, account, description, audience_id, or auth_account. With 7 parameters and no schema descriptions, this is insufficient coverage.

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

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

The description includes 'create a new custom audience' within the actions list, and the '[Flattened action: create]' clarifies the current tool's purpose. However, the opening line 'Manage Custom Audiences for targeting' is broader and also lists 'add_users', which belongs to a sibling tool, causing slight ambiguity about the specific resource.

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

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

It explicitly points to meta_ads_audience_delete for destructive delete, providing an alternative for a related operation. But it does not clearly state when to use this tool over meta_ads_audience_write_add_users, nor does it describe scenarios for creating audiences. The guidance is implicit rather than 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, idempotentHint=true, and destructiveHint=false, and the description's 'Read' matches those annotations. The description adds one useful behavior — accepting business_ids for batched execution — but does not explain how batched execution behaves, what auth requirements exist, or what data is returned beyond the listed resource names.

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 text is short and front-loaded with 'Read Facebook Business Manager data', but the multi-action list and the '[Flattened action: accounts]' note add ambiguity rather than clarity. Some of those action labels may not apply to this tool, so the structure is not fully aligned with the single-tool interface it describes.

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 tool has three optional-looking parameters, no output schema, and sparse annotations. The description leaves out return shape, pagination or output structure, and the exact difference between a single business_id and a batch of business_ids. This is enough to hint at intent but not enough for a confident standalone 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 compensate for the schema's silence. It only mentions business_ids for bulk support and does not explain business_id or auth_account, nor their relationship. A caller cannot confidently know what to provide without external knowledge.

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 identifies a read operation over Facebook Business Manager data and mentions 'accounts — ad accounts owned by a BM', which is relevant to the tool name. However, it then lists several other actions (list, pages, users, pixels) and only cryptically narrows via '[Flattened action: accounts]', making the actual purpose less crisp than it could be.

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 says 'Read' and mentions bulk support, but it gives no explicit guidance about when to choose this tool over sibling tools such as meta_ads_business_list, meta_ads_business_pages, meta_ads_business_users, or meta_ads_business_pixels. Without exclusions or alternatives, an agent must infer usage from the tool name and sibling list.

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 and idempotentHint=true, covering the read-only nature. The description adds that it performs a flattened action 'list' (so no mutations) and supports batched execution via business_ids, which is useful context. It doesn't mention pagination or rate limits, but annotations cover the safety profile.

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 compact, uses bullet points for actions, and includes a note about bulk support. It front-loads the purpose and provides a quick reference. No redundant 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?

Given the tool has a multi-action nature (list, accounts, pages, users, pixels) and only 3 parameters, the description adequately covers the main actions. But it lacks details on return format or parameter specifics, and with no output schema, a bit more clarity on what each action returns would improve completeness.

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 mentions business_ids for bulk support, but does not explain the purpose of business_id or auth_account. However, given the description lists actions that require business_id implicitly, it adds some meaning beyond the bare 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 clearly states it reads Facebook Business Manager data and enumerates specific actions (list, accounts, pages, users, pixels) with a flattened action 'list'. It distinguishes from sibling tools like meta_ads_business_accounts and meta_ads_business_pages by covering multiple resource types, and notes bulk support.

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 implies when to use this tool (for reading business manager data) and lists sub-actions, but does not explicitly say when not to use it or mention alternatives for specific resource types (e.g., meta_ads_business_accounts). The bulk support hint provides some context.

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

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

Annotations already declare readOnly, idempotent, and non-destruction; the description reinforces this with 'Read'. It adds useful behavioral context: resources, actions, and bulk execution via business_ids. No contradiction exists, and it gives more than safety only.

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 compact and front-loaded: starts with 'Read Facebook Business Manager data', uses tight action lines, and ends with a brisk bulk-support note. The 'Flattened action: page' line is a bit cryptic but not inflated; overall should kept 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?

Safety and idempotency are covered by annotations, and the description makes the resource scopes clear with action names. But with no output schema, the description does not clarify what the returned page data actually contains, nor does it resolve the Aabiguity between the full action list and the '[Flattened action]'. Compose for a read/list tool, still below fully self-suficient token.

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 descriptions cover 0%; description adds only 'Bulk support: service business_ids for batched execution.' That helps one parameter, but business_id and auth_account are semantically unexplained. The description does not adequately compensate for the 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?

The description clearly introduces the tool as 'Read Facebook Business Manager data' and lists specific actions such as 'pages — pages owned by a BM', backed by '[Flattened action: pages]'. This gives a solid verb+object purpose. However, the multi-action list makes it slightly less sharp than if it focused solely on the pages action.

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 says 'Bulk support' for business_ids, hinting at batched use, but it does not explain when to prefer this tool over siblings like meta_ads_business_accounts, meta_ads_business_users, or meta_ads_pages_list. No alternative guidance or exclusions are provided.

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 include readOnlyHint true, idempotentHint true, and destructiveHint false. The description confirms a read operation and adds 'bulk support' behavior, but doesn't disclose exact return behavior or required authentication. There is no contradiction with 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?

The description is relatively short and front-loaded, but it contains extraneous action lines (list, accounts, pages, users) that are not relevant to a pixels-specific tool with flattening. The bulk note is useful, but too much of the text could confuse or mislead.

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 tool lacks an output schema and must infer behavior. The present description establishes read-only pixel listing and bulk support, but it does not explain call shape, return format, or prerequisites such as auth_account. This is enough for a narrow list tool but leaves important 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 should compensate. It only explains that business_ids are used for bulk execution; it does not explain business_id's role, auth_account, or the relationship between the singular and plural business identifiers.

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 explicitly explains that the tool reads Facebook Business Manager data and includes 'pixels — pixels owned by a BM' with '[Flattened action: pixels]', so the targeted resource is clear. It is slightly diluted by listing other unrelated actions (list, accounts, pages, users), but the flattened action note pins the purpose.

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 context is mostly implied: the tool name plus 'pixels' action signal when to choose it. The only explicit usage guidance is 'Bulk support: accepts business_ids for batched execution,' so there is no clear when/neither-or alternative guidance regard to sibling 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?

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds a few useful behaviors: the tool reads Facebook Business Manager data and accepts business_ids for batched execution. It does not contradict the annotations, but it adds little beyond those basic 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 not excessively long, but it spends most of its length listing unrelated actions that do not belong to a users-only flattened tool. The four non-user actions create noise and re-introduce ambiguity. A clear sentence such as 'Read users and system users for a Facebook Business Manager' would be far more concise and precise.

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 read-only listing tool, the description should identify the target resource, the accepted identifiers, and any batch behavior. It identifies the resource but leaves business_id and auth_account ambiguous, does not say what the response contains beyond users, and does not clarify what 'Flattened action: users' means operationally.

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 explain the parameters, but it only mentions that business_ids is used for batched execution. The meaning of business_id and especially auth_account is not explained. An agent would have to infer these from their names and the surrounding tool context.

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 begins with 'Read Facebook Business Manager data' and the 'users' line mentions business users and system users, so the core purpose is recognizable. However, it lists five action types (list, accounts, pages, users, pixels) before the bracketed '[Flattened action: users]', which obscures the actual single action and blurs the distinction from sibling tools like meta_ads_business_pages and meta_ads_business_accounts.

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 explicit guidance about when to use this tool versus sibling tools such as meta_ads_business_accounts, meta_ads_business_pages, meta_ads_business_pixels, or meta_ads_business_list. The action list actually suggests this tool can be used for non-user actions, and the 'Flattened action: users' note is too implicit to serve as firm usage direction.

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 mark the tool destructive, and the description goes beyond this by specifying 'Permanently delete' and 'Irreversible', which is meaningful because destructive could otherwise include soft-deletes. It also discloses batched execution via campaign_ids, a behavioral trait not present in the annotations, but it does not mention auth requirements or side effects on associated ads/ad sets.

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

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

The description is two crisp sentences with the key action front-loaded. 'Irreversible' and the bulk-support line add essential information without padding or repetition of the tool name.

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 destructive mutation tool with no output schema, this description is too thin: auth_account is unexplained, batch-mode semantics conflict with the required campaign_id in the schema, and there is no statement of what happens to sub-objects. It provides a warning but not enough to invoke confidently in all supported modes.

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 schema description coverage at 0%, the description was expected to compensate, but it only hints at campaign_ids as the batch parameter. It leaves campaign_id and auth_account unexplained and does not clarify whether campaign_id is still needed when campaign_ids is supplied, which is a real invocation ambiguity.

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 'Permanently delete a Meta Ads campaign', a specific verb + resource statement that unambiguously identifies the tool. It is clearly distinct from sibling tools like meta_ads_campaign_write_pause/update and other *_delete tools by naming campaign as the object.

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 'Irreversible' warning implies a destructive intent and suggests not to use this when a pause/update would suffice, but the description never directly names alternatives or states when not to use it. The bulk-support note gives some usage context, yet there is no explicit guidance around replacing with meta_ads_campaign_write_pause for temporary stops.

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 and destructiveHint=false, so the safety profile is covered. The description adds value by specifying the exact fields returned (id, name, status, objective, budget, dates) and the behavior of include_paused. It does not discuss pagination or authentication, but the read-only nature is clear from annotations, and the added details are useful beyond 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 sentences with front-loaded action and return fields. No fluff, no redundancy. Every word adds value, and it avoids repeating schema or annotation details.

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 tool is simple with no output schema, and the description covers core functionality and return values. However, the lack of explanation for account and auth_account leaves a gap for agents unfamiliar with Meta Ads conventions. The description is adequate for a minimal list tool but not fully complete given the parameter coverage issue.

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

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

Schema description coverage is 0%, so the description must compensate for all parameters. It explains only include_paused (booleans to include paused campaigns). The parameters 'account' and 'auth_account' are left undocumented, leaving the agent to guess their meaning or rely on the schema types only. This partial coverage is insufficient given zero schema-level descriptions.

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 'List Meta Ads campaigns' with a clear verb and resource. It enumerates return fields (id, name, status, etc.), which differentiates it from related sibling tools like meta_ads_campaign_delete or meta_ads_campaign_write_activate. The purpose is unambiguous and 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?

The description gives a clear context for using the tool (to list campaigns) but does not explicitly contrast it with alternatives or state when not to use it. It only mentions the include_paused option for filtering. Given the sibling list, usage is implied, but no explicit guidance on choosing this over other campaign tools is provided.

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?

Beyond the annotations, the description discloses meaningful behavioral traits: actions are mutating, delete behavior is explicitly outsourced to a sibling, budget values are cents, and budget placement changes ad set budget rules. This adds real operational context without contradicting the 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?

The structure is well front-loaded and readable with a clear one-line summary followed by compact bullets. The objectives list duplicates the schema enum and the action list spreads beyond the apparent 'activate' focus, but the overall length is still reasonable and mostly purposeful.

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 11 schema parameters and no output schema, the description covers the main intent and budget semantics but not enough to fully invoke the flattened 'activate' action: it does not clarify exact required fields for activation, the distinction between single vs batch IDs, expected return behavior, or semantics of several 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 description adds value by explaining budgets, objectives, the create/update/pause/activate actions, and bulk campaign_ids support. However, it leaves many schema parameters undocumented or underdescribed, including bid_strategy, campaign_id vs campaign_ids, status values, account/auth_account, special_ad_categories, and daily_budget vs lifetime_budget.

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 clearly identifies the resource (Meta Ads campaigns) and the available actions (create, update, pause, activate), and it distinguishes itself from the destructive delete sibling. However, it does not fully differentiate this tool from the sibling meta_ads_campaign_write_create/update/pause tools, which creates potential action-selection ambiguity.

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 useful usage context: destructive delete should go to meta_ads_campaign_delete, budgets are in cents, and campaign budget implies campaign budget optimization. However, it does not explicitly say when to use this tool over meta_ads_campaign_write_create, meta_ads_campaign_write_update, or meta_ads_campaign_write_pause, so the 'when-to-use' guidance is only partially implicit.

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, and idempotentHint=false, which already indicate this is a mutating, non-destructive, non-idempotent operation. The description adds valuable context: budgets are in cents, campaign budget optimization means ad sets must not carry their own budget, and bulk support via campaign_ids. It does not contradict annotations. It could mention that updates are not idempotent, but the annotations already cover that, so the description adds sufficient extra 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?

The description is well-structured with a clear action list, objectives, budget notes, and a pointer to the delete tool. It is front-loaded with the main purpose. The 'Flattened action: create' line is a bit cryptic and could be confusing, but it's short. The bulk support note is useful. Overall, it's concise and organized, though the flattened action line adds little value.

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

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

Given the tool's complexity (11 parameters, 4 actions, no output schema, no annotations beyond basic hints), the description covers the core semantics well: actions, objectives, budget units, and the critical budget optimization rule. It also mentions bulk support. However, it does not explain the return value or error behavior, and some parameters (bid_strategy, special_ad_categories) are not described. For a tool with this many parameters and no output schema, it is reasonably complete but not exhaustive.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the meaning of 'budget' (in cents, with example), the relationship between campaign budget and ad set budgets, and the objective enum values are listed. It also clarifies that 'campaign_ids' enables bulk execution. However, it does not explain parameters like 'account', 'auth_account', 'bid_strategy', 'special_ad_categories', or the difference between 'daily_budget' and 'lifetime_budget', which are left to the schema. Given the 0% coverage, the description adds significant value but still leaves gaps.

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 clearly states the tool creates, updates, pauses, or activates Meta Ads campaigns, with a specific verb and resource. It distinguishes itself from siblings by listing the four actions and explicitly pointing to meta_ads_campaign_delete for destructive deletes, and the sibling list includes separate pause/activate/update tools, making this tool's role as a combined write tool 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?

The description provides explicit guidance on when to use this tool versus alternatives: it lists the four actions (create, update, pause, activate), notes that pause and activate are shortcuts, and explicitly says 'For destructive delete use meta_ads_campaign_delete instead.' It also explains the budget behavior (campaign budget optimization vs. per-ad-set budgeting), which is critical for correct usage.

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 adds significant context beyond the annotations: budget in cents (5000 = $50), campaign budget optimization constraint (ad sets must not carry budget if campaign budget is set), and the option to leave budget empty for per-ad-set budgeting. These are behavioral traits not captured by annotations. However, it does not disclose other behaviors such as required permissions or rate limits, but the provided details are 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 description is concise and well-structured: a list of actions with a one-line purpose each, followed by critical notes on objectives, budgets, and deletion. It is front-loaded with the clear purpose and actions, and every sentence contributes meaningful information without 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?

Given the tool complexity (11 params, multiple actions) and lack of output schema, the description is fairly complete: it covers all actions, objectives, budget nuances, and bulk support. It misses some parameter detail (e.g., bid_strategy, special_ad_categories), but the core semantics are addressed. It also provides a cross-reference to the delete tool, enhancing contextual completeness. A score of 4 is appropriate, as some parameter semantics remain undocumented.

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

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

The schema has 11 parameters with 0% description coverage, so the description must compensate. It explains the semantics of 'budget' (daily_budget and lifetime_budget implicitly) in cents and the CBO relationship, and enumerates the objective enum values. It also mentions 'name' and 'status' when describing create and update actions, helping to map parameters to actions. The description does not cover all parameters but addresses the most critical 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?

The description clearly states it can create, update, pause, or activate Meta Ads campaigns, and names the specific actions. It distinguishes itself from siblings by noting the flattened action 'pause' and pointing to meta_ads_campaign_delete for destructive deletes, and is clearly differentiated from the sibling write tools like meta_ads_campaign_write_create and meta_ads_campaign_write_update.

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

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

It provides clear context on when to use it for campaign management actions and when not to (for destructive delete). It also mentions bulk support and clarifies budget handling, but does not explicitly exclude other similar write tools by name, though the action list and reference to delete tool provide adequate 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 mark the tool as non-read-only and non-destructive; the description adds meaningful behavior beyond that: budgets are in cents, campaign budget optimization means ad sets must not carry their own budgets, leaving the campaign budget empty switches to per-ad-set budgeting, and bulk execution is supported. It doesn't disclose auth needs or response shape, but the added context is substantive.

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 structured with actions, objectives, budget rules, a delete pointer, and a bulk-support note. It is front-loaded and mostly efficient, though the 'Flattened action: update' line is cryptic and could be clarified or removed.

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 complex 11-parameter write tool with no output schema and minimal annotations, the description covers core actions, budget semantics, objectives, and bulk support. However, it omits several parameter behaviors (daily vs lifetime budget, bid_strategy, special_ad_categories) and return/response expectations, making it adequate but with clear gaps.

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

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

With 0% schema description coverage, the description compensates for core parameters: name, objective, budget (in cents), status/pause/activate, and campaign_ids. However, it leaves daily_budget vs lifetime_budget, bid_strategy, special_ad_categories, and account/auth_account unexplained, so it only partially covers the 11-parameter surface.

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 clearly states it creates, updates, pauses, or activates Meta Ads campaigns and names concrete actions. It explicitly routes destructive deletion to a sibling tool, but it doesn't differentiate from the sibling create/pause/activate tools, and the 'Flattened action: update' note muddies the actual 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?

Provides some usage guidance: it says delete should go to meta_ads_campaign_delete, explains the campaign-budget-optimization constraint, and notes bulk execution via campaign_ids. However, it never clarifies when to prefer this tool over the sibling meta_ads_campaign_write_create, meta_ads_campaign_write_pause, or meta_ads_campaign_write_activate tools, leaving overlap unresolved.

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?

Although annotations already mark the tool as destructive, the description adds meaningful behavioral context: deletion is permanent and irreversible. It also discloses bulk execution support via ad_ids, which goes beyond the structured 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?

The description is extremely concise, front-loads the core message, and adds only the high-value detail about bulk support. Every sentence earns its place with no wasted text.

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

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

The description covers the destructive nature, irreversibility, and bulk capability, which is reasonable for a delete tool with strong annotations. However, the lack of parameter semantics and absence of any guidance on batch vs single deletion leaves the description incomplete for a fully informed agent.

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

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

Schema description coverage is 0%, so the description must compensate for parameter ambiguity. It only explains ad_ids for batching and does not clarify the relationship between ad_id and ad_ids, nor the purpose of auth_account. This leaves key invocation semantics underspecified.

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 clearly identifies the action ('Permanently delete') and the resource ('a Meta Ads ad'), making the tool's purpose unmistakable. It also differentiates from sibling delete tools by naming the 'ad' resource rather than adset, campaign, or audience.

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 no guidance on when to use this tool over sibling delete tools, nor when not to use it. The bulk-support note hints at one usage scenario, but there is no explicit direction about prerequisites, alternatives, or exclusion cases.

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=false, indicating a non-read, non-destructive operation. The description adds useful context about required inputs for create_creative (page_id, image_hash/video_id) and lists CTA enum values, plus bulk support. However, it does not discuss idempotency, return values, or side effects of updates, which would enhance transparency beyond the annotations. No contradiction with 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?

The description is not excessively long, but it is cluttered by listing three actions when only one is the flattened action, and the 'Flattened action: create_ad' aside adds confusion. The structure could be improved by stating the primary action upfront and referencing sibling tools for other actions, making it more concise and clearer.

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

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

With 18 parameters, no required parameters, no output schema, and minimal annotations, the tool is high-complexity. The description provides some high-level guidance (CTA options, bulk support, deletion alternative) but omits critical details such as which inputs are necessary for create_ad, how account/auth_account are used, what the return value looks like, and how bulk execution behaves. This is insufficient for an agent to confidently invoke the tool.

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

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

The input schema has 0% description coverage, so the description carries the full burden of explaining parameters. It explains image_hash, video_id, page_id, message, call_to_action_type, and the plural bulk fields (page_ids, video_ids, adset_ids, creative_ids, ad_ids). Yet many other parameters (link, name, ad_id, adset_id, status, account, auth_account, creative_id) remain unexplained, leaving significant gaps in parameter understanding.

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 clearly states it 'Create ad creatives and ads (final step to launch)', which identifies the core action. However, it lists multiple actions (create_creative, create_ad, update_ad) that overlap with dedicated sibling tools, creating ambiguity about the tool's specific role. The 'Flattened action: create_ad' note partially resolves this but is not fully 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?

The description provides one explicit alternative ('For destructive delete use meta_ads_creative_delete') but does not explain when to use this tool versus the sibling tools meta_ads_creative_write_create_creative or meta_ads_creative_write_update_ad, even though those actions are listed. The presence of dedicated siblings and the 'flattened action' statement leave usage guidance ambiguous.

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?

Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description states this is a write-oriented workflow, requires prior upload via upload_image/upload_video, and discloses bulk support through array parameters. It also adds the destructive delete pointer, which helps the agent avoid assuming this tool handles deletion.

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 compact, front-loaded with the main purpose, and uses structured sections for actions, requirements, and bulk behavior. There is slight overlap between the action bullets and the later create_creative detail, but the text avoids unnecessary padding.

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

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

For a high-parameter, no-output-schema write tool, the description provides useful context: final launch step, required media dependencies, CTA examples, and bulk support. It still leaves gaps around success return values, how account/auth_account would be used, and the exact behavior of the optional ad creation/update 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?

Since the schema has 0% description coverage, the description must compensate, and it does explain key parameters: page_id, image_hash/video_id, message, call_to_action_type, and the bulk plural IDs. However, several parameters such as link, name, account, auth_account, creative_id, and status remain unexplained, so compensation is partial for 18 total 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 clearly states the tool "Create ad creatives and ads (final step to launch)" and explains the core create_creative action with media and copy requirements. It does not strongly differentiate itself from the sibling tools meta_ads_creative_write_create_ad and meta_ads_creative_write_update_ad, and actually lists create_ad/update_ad inside its own description, which prevents a score of 5.

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

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

The description gives useful conditions: create_creative requires page_id and either image_hash or video_id plus message, and it directs destructive operations to meta_ads_creative_delete. However, it does not explicitly say when to favor the sibling create_ad/update_ad tools or when not to use this tool, so usage guidance remains mostly implicit.

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 are all false and uninformative, so the description carries the full burden. It does not state whether update_ad performs a partial or full replacement, whether it preserves unspecified fields, what the API returns, or any side effects. The top-level "Create ad creatives and ads" line actively misaligns with the flattened update action, reducing transparency about the real 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?

The text is well-structured around a bullet action list and concisely flags bulk support and the delete alternative. However, the inclusion of non-relevant create/create_creative details and the conflicting headline make it longer than needed for the actual flattened update_ad action, and there is redundant bookkeeping such as the repeated closure.

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

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

For an 18-parameter tool with no required parameters, no output schema, and empty annotations, this description is not complete enough to guide a trustworthy update invocation. It valuable for the create_-preceding-actions, but omits details about the update operation itself, such as how the creative is associated, how status/name changes apply, whether image/video components are accepted on update, and what response is returned.

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?

Since schema description coverage is 0%, the description attempts to provide semantics: it explains image_hash, video_id, page_id, and message for create_creative (even though that is not this flattened action), and the status/creative/name fields for update_ad. It also covers CTA enum values and mentions bulk array support, but many of the 18 parameters, especially auth_account/account/creative_ids, remain unexplained or only vaguely tied to the bulk support note.

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 contains a clear line "update_ad — update ad fields (name, status, creative)" which does name the intended action, but the opening "Create ad creatives and ads" and the multi-action list obscure whether this tool creates, updates, or both. The "[Flattened action: update_ad]" note clarifies the actual scope, yet it does not effectively differentiate this tool from sibling create_a/create_creative tools in the description.

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 an alternative for delete ("For destructive delete use meta_ads_creative_delete") and a terse update_ad action line, but it never explains when to use this tool rather than meta_ads_creative_write_create_ad or meta_ads_creative_write_create_creative. Most guideline text is about creating the create_creative flow, which is not relevant to the flattened update_ad action.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds value by detailing the exact return fields (connections[] and ad_accounts[] with specific properties), which helps the agent understand what to expect. It doesn't discuss pagination or rate limits, but for a simple list operation, this is sufficient.

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, well-structured sentence that front-loads the primary action, then provides specific return details and a practical usage note. There is no fluff; every part adds value.

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

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

The description gives a clear picture of the output and how to use it, but fails to explain the sole input parameter, which is a notable gap given the low schema coverage. It also omits any mention of limitations (e.g., pagination, authentication prerequisites). For a simple list tool with one optional param, this is not fully complete.

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

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

The only parameter 'auth_account' is entirely unexplained. Schema description coverage is 0%, so the description should compensate by describing its purpose. It is optional, but there is no indication of what it does (e.g., which authentication account to use). The description mentions OAuth logins in the response but does not connect this to the parameter, leaving the agent guessing.

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 clearly states it lists Meta connections and ad accounts, specifying the return structure with details like id (act_XXX), name, currency, timezone, status. This is a specific verb+resource that distinguishes it from other meta_ads list tools by the combination of connections and ad accounts.

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

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

It provides context on why to use this tool: to obtain the ad_account_id for use in other tools ('Use the ad_account_id in `account` on the other tools'). This implies it is an entry point, but does not explicitly state when not to use it or name alternative tools like meta_ads_business_list for business-level listings.

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's read-only claim ('List uploaded media') is consistent with the annotations readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so there is no contradiction. However, it adds little beyond the annotations: it does not mention pagination, authentication requirements, or what kind of media metadata is returned.

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

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

The description is short and front-loaded with the core action, but the 'Actions: list_images, list_videos' and '[Flattened action: list_images]' lines are redundant and potentially confusing for a specific tool. It is concise but not cleanly structured.

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

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

Given no output schema and minimal parameter documentation, the description should provide more context about return values, filtering, or when to use the sibling upload/list tools. The current text covers only the basic operation and relies heavily on annotations and the tool name to fill 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?

The schema has 0% description coverage for the two parameters, and the description only hints at 'the ad account' as context. It does not explain the required format or role of 'account' or the meaning of 'auth_account', leaving both parameters largely underdocumented.

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 clearly states a read-only listing action ('List uploaded media in the ad account') and the flattened action 'list_images' pins the specific operation. It is mostly specific, though 'media' plus the mention of 'list_videos' slightly dilutes image-only clarity and could be confused with the sibling tool meta_ads_media_list_videos.

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 is provided for when to use this tool versus alternatives. The description lists 'list_images, list_videos' and there is a sibling tool named meta_ads_media_list_videos, but it never explicitly says to choose this tool for images or explains exclusions such as video uploads.

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 disclose readOnly, idempotent, non-destructive behavior. The description adds minimal context by scoping the operation to uploaded media in the ad account, but does not mention pagination, return shape, or account/auth handling.

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 short but includes extraneous lines such as 'Actions: list_images, list_videos' and '[Flattened action: list_videos]' that add noise rather than useful selection information. The first sentence is clear and front-loaded, but the rest is not fully purposeful.

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?

This is a simple list operation, but the description lacks parameter semantics, alternative guidance, and output expectations. Since there is no output schema, the description should compensate by explaining what the video list contains or how results are returned, which it does not.

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 input schema has two parameters (account, auth_account) with 0% schema description coverage, and the description does not explain the meaning, format, or required role of either parameter. This leaves the agent without adequate parameter-level guidance.

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

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

The description says 'List uploaded media in the ad account' and specifically identifies the flattened action as list_videos, which clearly conveys that the tool lists video media. However, the mention of list_images alongside list_videos adds slight ambiguity and prevents a perfect score.

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 usage guidance is provided about when to prefer this tool over meta_ads_media_list_images or other media-related tools. The description lists action names but does not explain context, prerequisites, or exclusions.

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 adds useful behavioral context beyond annotations, such as 'Meta fetches it' for videos and 'keeps file out of AI context' for get_upload_command. However, it does not disclose whether generating the curl command has side effects, requires authentication, or what the command execution entails. No contradiction with annotations was 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?

The description is well-structured with a bulleted action list and a helpful pointer to a sibling tool. It is concise and front-loaded. The only issue is that the opening summary mentions upload_image and upload_video even though the flattened action is get_upload_command, which adds minor noise.

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

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

With six parameters, no required fields, no output schema, and no parameter descriptions, the description leaves important gaps: it does not state what the curl command output looks like, how to use it, which parameters are needed, or whether auth_account is required. The tool is simple in concept, but the description alone is not enough 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%, so the description must compensate for the six undocumented parameters. It indirectly maps image_url, video_url, and file_path by mentioning URLs and local video files, but it does not explain title, account, auth_account, or which parameters are required for get_upload_command. This is insufficient for reliable invocation.

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 clearly identifies get_upload_command as returning a curl command for uploading large local video files, which is a specific verb+resource+scope. It also distinguishes itself from listing media by pointing to meta_ads_media. However, the opening line 'Upload images and videos to Meta Ads account' and the listing of three actions create some ambiguity given the flattened action is only get_upload_command.

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 clear context for when to use get_upload_command: for large local video files where keeping the file out of AI context matters. It also explicitly directs users to meta_ads_media for listing already-uploaded media. It does not explicitly contrast with the sibling upload_image/upload_video tools, but the use case is reasonably 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 already indicate this is a write operation (readOnlyHint false). The description adds that it returns an image hash for creatives, which is useful. It does not mention authentication requirements, side effects, error behavior, or whether the image is fetched asynchronously. The description adds some context but not rich behavioral detail beyond the annotation.

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 not concise for its actual purpose. It includes actions for video upload and curl command generation, which are not part of this tool (as per the flattened action note). This adds clutter and is potentially misleading. The focused upload_image information is brief, but the extra content reduces clarity and efficiency.

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

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

Given the complexity (6 parameters, no output schema, minimal annotations), the description is incomplete. It fails to explain the parameters, does not mention authentication or account selection, and provides no details on error handling or access requirements. The reference to listing media is helpful, but overall the tool's usage context 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?

Schema coverage is 0%, meaning the description must explain the parameters. It only indirectly references the image URL via the action description; other parameters like account, auth_account, title, and file_path are not explained. There is no mapping of parameters to their purposes, which leaves the agent guessing about required inputs. This is a significant 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 states the core action: 'upload image from URL' and specifies the output ('Returns image hash for use in creatives'). It also distinguishes from listing via the reference to 'meta_ads_media'. However, the top line 'Upload images and videos' and the inclusion of video and curl command actions could confuse, but the flattened action note clarifies this tool is specifically for upload_image. Overall, the primary purpose is clear and distinct from 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?

The description provides a clear alternative for listing media ('For listing already-uploaded media use meta_ads_media.') and implies that this tool is for image upload via the action list. However, it does not explicitly contrast with the video upload tool or explain under what conditions to use this vs. other upload tools. It also lacks guidance on prerequisites or selection criteria beyond the URL-based upload.

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 declare readOnlyHint:false, so the description must disclose write-side behavior. It mentions 'Meta fetches it' and that upload_video 'Returns video_id', which is helpful, but it omits any side effects, auth requirements, processing delays, or file constraints. It also includes details about get_upload_command that are irrelevant to the flattened action, adding noise without enriching the core upload_video 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?

The text is a compact list of actions but not front-loaded with the primary purpose. The 'Flattened action' note is at the very end, and the inclusion of two extra actions dilutes the main scope. It is not excessively verbose, yet the structure could be improved by leading with 'Uploads a video to Meta Ads' and clarifying the scope upfront.

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 write operation with no output schema, no parameter guidance, and no annotation coverage beyond readOnlyHint, the description is insufficient. It does not describe return values (besides video_id, which is mentioned but not formally), error conditions, or how this relates to the broader Meta Ads creative workflow. It fails to add the context needed for a successful 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?

With 6 parameters, none required, and 0% schema description coverage, the description must explain each parameter. It does not. The sub-action listing mentions 'upload video from URL' but does not clarify which parameter holds the URL (video_url vs file_path), nor the roles of title, account, or auth_account. The agent cannot correctly map inputs without external knowledge.

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 'Upload images and videos to Meta Ads account' but the tool name is specifically for uploading videos, creating ambiguity. It lists three sub-actions (upload_image, upload_video, get_upload_command) when the tool is flattened to upload_video, and the note 'Flattened action: upload_video' is buried at the end. This does not clearly distinguish it from sibling tools like meta_ads_media_write_upload_image or meta_ads_media_write_get_upload_command.

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 only one explicit guidance: 'For listing already-uploaded media use meta_ads_media.' No guidance on when to use this tool vs. the image upload or get-upload-command siblings, nor any prerequisites for video upload (e.g., file_format, size limits). The mention of 'large local video files' for get_upload_command implies a scenario but does not clarify when to choose this tool over others.

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 read-only, idempotent, and non-destructive behavior, and the description's 'Read Facebook Pages data' is consistent with those. It adds the action structure and bulk support details, but the meaning of '[Flattened action: insights]' remains ambiguous and auth/selection behavior is not explained.

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 front-loaded, compact, and scannable with an action list and short output summaries. The '[Flattened action: insights]' line is cryptic but not bloated, so the overall structure is 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?

For a read-only multi-action tool with no output schema, the description gives a reasonable baseline by naming actions and return metrics. However, it is not fully complete because it does not clarify how to select an action, how parameters map to actions, or why this tool exists alongside sibling tools with overlapping names.

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 needed to compensate, but it only partially does. It confirms page_ids/post_ids enable batched execution and per-action outputs, but does not clarify how page_id, post_id, period, and auth_account relate to the different actions.

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 clearly states it reads Facebook Pages data and lists concrete actions (list, insights, posts, post_insights) with their returned metrics. However, it does not differentiate this composite tool from sibling tools like meta_ads_pages_list or meta_ads_pages_posts.

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 explicit guidance is given about when to use this tool versus the more specific page tools. The description mentions bulk support and the actions available, but does not say which tool should be preferred or when each action should be selected.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, which covers the safety profile. The description adds that it supports bulk execution (page_ids, post_ids) and the flattened action 'list', but does not mention any limitations, auth requirements, or response structure beyond what is implied.

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 concise and front-loaded with 'Read Facebook Pages data.' However, the list of actions is somewhat repetitive and could be more structured. It includes a clutter marker '[Flattened action: list]' which is confusing and not explanatory.

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 tool has 6 parameters, no output schema, and no schema description coverage, so the description is the main source of semantic info. It covers the actions and bulk support, but lacks critical details like parameter requirements for each action, return format, and pagination. Sibling tools have specific names (e.g., meta_ads_pages_insights) that may overlap, so more guidance is needed.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions 'period', 'page_id', 'post_id', 'page_ids', 'post_ids' in the actions, but does not explain the meaning of 'auth_account' or the interaction between parameters (e.g., which are required for which action). The bulk support mention adds some value, but it's incomplete.

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 lists multiple actions (list, insights, posts, post_insights) but flattens to 'list', so the primary purpose is to read Facebook Pages data. It specifies the resource (Facebook Pages) and the verb (Read), and distinguishes from siblings like meta_ads_pages_insights and meta_ads_pages_posts, which likely have more specific 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?

The description mentions bulk support and the actions, but does not explicitly state when to use this tool versus siblings like meta_ads_pages_insights or meta_ads_pages_posts. The flattened action implies the default is 'list', but no exclusions or alternative recommendations are provided.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful behavioral context about being a flattened action and supporting bulk execution via arrays. It does not add details on pagination, rate limits, or output format, but the annotation coverage lowers the burden. No contradiction with 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?

The description includes a four-action list even though only post_insights is the actual flattened action, adding unnecessary clutter. The '[Flattened action: post_insights]' note and bulk support line are useful, but the action list could be substantially trimmed. It is not appropriately sized for the tool's actual purpose.

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 tool has 6 parameters and no output schema, and the description provides no explanation of return values or how the output is structured. It also does not clarify the relationship between the multiple actions listed, the flattened action, and sibling tools like meta_ads_pages_insights. Bulk support is mentioned, but period/auth_account semantics are absent, making the contextual picture 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 compensate. It explains page_id and post_id via the action descriptions and page_ids/post_ids via the bulk support sentence. However, it does not explain the 'period' parameter (beyond the schema enum) or 'auth_account', leaving a gap for those parameters. The ID semantics are clear, but the compensation is incomplete.

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 'Read Facebook Pages data' and lists actions, with a direct definition of 'post_insights — detailed insights for a specific post'. However, listing list/insights/posts alongside post_insights creates ambiguity about the actual scope, especially since the actual tool is '[Flattened action: post_insights]'. It does not clearly differentiate from sibling tools like meta_ads_pages_insights or meta_ads_pages_posts.

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 explicit guidance on when to use this tool versus alternatives such as meta_ads_pages_insights or meta_ads_pages_posts. The description implies usage for detailed post-level insights and mentions bulk support with page_ids/post_ids, but it does not state exclusions or situational recommendations. This is less than the 'implied usage' threshold because the action list muddles the intended context.

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

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

Annotations indicate readOnlyHint=true and destructiveHint=false, which the description aligns with by stating 'Read Facebook Pages data.' The description adds value by specifying the actions are read-only and mentions bulk execution, which is not in annotations. No contradiction 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?

The description is fairly concise and uses a bulleted list for actions, but it includes a redundant line '[Flattened action: posts]' which is unclear and adds noise without clear benefit.

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

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

Given the tool has 6 parameters and no output schema, the description provides the basics (actions and sample fields) but misses critical details like the full set of parameters (period, auth_account) and any return structure. However, the read-only annotation mitigates some complexity, making it minimally complete.

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

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

The schema has 0% coverage and 6 parameters, but the description only hints at page_ids, post_ids for bulk and the page_id for insights. It does not explain the meaning of period, auth_account, or the distinction between page_id and page_ids, leaving the agent to infer usage.

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 clearly states it reads Facebook Pages data and enumerates four action types (list, insights, posts, post_insights) with specific fields (e.g., name, fan_count, likes). However, it does not distinguish these actions from sibling tools like meta_ads_pages_insights and meta_ads_pages_list, which likely overlap.

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

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

Description mentions bulk support but gives no guidance on when to use this tool versus sibling tools like meta_ads_pages_insights or meta_ads_pages_post_insights. It does not specify the context for each action or when to prefer a more specialized tool.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful context about the temporal window ('today'), per-ad granularity, and the fact that campaign/adset/creative details plus _summary are returned; no contradiction.

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, front-loads the main purpose and then enumerates output coverage. No filler 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?

With no output schema and no parameter descriptions, the description must carry more weight. It does specify output content (per-ad hourly stats, campaign/adset/creative details, _summary), but omits input parameter semantics and usage context, making it insufficiently complete for a 2-parameter tool among many dashboard siblings.

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

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

Schema coverage is 0% and the description does not explain account or auth_account, how they relate, or whether they are required. The names offer weak hints but no semantic guidance, so the description fails to compensate for the schema's lack of 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?

The description uses a specific verb ('Shows') with a specific resource: an hourly realtime dashboard for today, with per-ad breakdown and hourly stats. This content differs from sibling tools like meta_ads_today or meta_ads_ads, so the tool's function is identifiable.

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

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

No explicit when-to-use or alternative-avoidance guidance is included. The 'Hourly realtime dashboard for today' phrase implies temporal scope, but does not explain when to prefer this over meta_ads_today or meta_ads_ads, nor when not to use it.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds valuable behavior: includes ads in ANY status, defaults to current month, returns per-row metrics plus _summary. This goes beyond the annotations and helps the agent understand side effects (none) and data scope.

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 sentences, front-loaded with the core definition, then specific usage guidance, then return format. Every sentence earns its place; no fluff or repetition of schema/annotations.

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

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

Given no output schema, the description does mention return contents ('per-row spend, revenue, ROAS, plus _summary') which partially compensates. With 5 params, no required params, and rich annotations, the description covers the main behavioral nuances (status inclusion, levels, default date range). Some param details like date format are missing, but overall complete enough.

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

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

Schema description coverage is 0%, so the description must compensate. It explains 'level' with concrete options (ad, account, campaign) and gives default behavior for date range. However, it does not describe 'since', 'until', 'account', or 'auth_account' formats or semantics; the level guidance and default context help but leave gaps.

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 clearly states the tool computes ROAS for a date range using Meta's /insights endpoint, names the specific resource (Meta ads insights), and distinguishes from siblings by covering ALL ad statuses (ACTIVE/PAUSED/DISABLED/ARCHIVED) and defaulting to current month. It also differentiates levels (ad/account/campaign) which separates it from other meta_ads_* tools.

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

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

It explicitly says when to use which level: 'For account totals use level=account; for per-campaign view use level=campaign' and defaults to current month. It doesn't explicitly name alternatives among siblings (e.g., meta_ads_realtime, meta_ads_today) but the date-range/level guidance gives clear context. Missing explicit when-not-to-use, but adequate.

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 provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds specific behavioral details such as 'check expiry date' and 'list scopes,' which go beyond the annotations. It does not contradict the structured hints and offers useful context about the token validation process.

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 concise sentence that efficiently enumerates the tool's capabilities. No redundant phrasing, front-loaded with core actions. This is exemplary conciseness.

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

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

Given the lack of output schema and the undocumented parameter, the description is under-specified. It does not mention what the tool returns (though 'list' implies some output) or how the auth_account parameter should be used. The tool's complexity is low, but the missing parameter explanation and lack of return format limit its completeness for an agent to correctly invoke it.

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 one parameter (auth_account) with no description, and schema_description_coverage is 0%. The description does not explain the purpose or expected format of this parameter. An agent has no clue whether to pass a token, account ID, or something else. The description entirely 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?

The description clearly states the tool's actions: 'Validate Facebook token, check expiry date, list connected ad accounts and scopes.' It uses a specific verb-resource structure and distinguishes the tool's diagnostic purpose from sibling listing tools like meta_ads_list_accounts and meta_ads_business_accounts. The scope 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?

No explicit guidance on when to use this tool versus alternatives. The description simply states what it does without indicating prerequisites, typical workflows, or when to prefer sibling tools. The context of many account-listing tools suggests this might be a pre-flight check, but that is not 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?

The description does not add behavioral details beyond the annotations. It simply states it 'returns' metrics, which aligns with the readOnlyHint and idempotentHint. There is no mention of side effects, rate limits, or data freshness, but since the annotations already cover safety and non-destructiveness, the description adds minimal extra transparency.

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 sentence that front-loads the core purpose ('Today's ad performance dashboard') and then lists the return values in a compact list. It avoids redundancy and includes all essential output details without excess wording.

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

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

The description adequately explains the return values, which is helpful given no output schema is present. However, it omits any explanation of the input parameters and does not mention potential edge cases (e.g., what happens when no ads exist). For a simple tool, the core output is covered, but the lack of parameter context reduces completeness.

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 description provides no information about the parameters (account, auth_account, include_zero). It does not explain how 'account' is used or what 'include_zero' controls. With 0% schema coverage and no compensation, the description fails to clarify parameter meanings, making it difficult for an agent to correctly invoke the 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 clearly states the tool's function: 'Today's ad performance dashboard' and enumerates the exact metrics returned (spend, revenue, ROAS, CPA, impressions, clicks, CTR) plus an aggregate. This precisely conveys what the tool does and distinguishes it from other ad-related tools that might focus on campaign management or real-time data.

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 lacks explicit usage guidance. It does not mention when to prefer this tool over siblings like meta_ads_realtime or meta_ads_ads, nor does it state conditions such as 'use for daily summaries' or 'requires an active account'. The word 'Today's' implies a time scope, but it is not explicitly framed as a usage condition.

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 convey that this is not read-only, is idempotent, and is not destructive. The description adds the useful behavioral detail that the conversation array should be included for reproduction, but does not disclose what happens after reporting (e.g., ticket creation, confirmation). No contradiction with 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?

The description is a single, front-loaded sentence with no filler. Every clause adds value: it states the purpose and the key reproduction instruction.

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

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

For a simple tool with three parameters and no output schema, the description is largely sufficient. It covers the tool's purpose and the most important usage nuance (conversation array), while the schema handles required/optional parameter 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 the description must compensate. It only explains the conversation parameter ('recent messages for reproduction') and leaves the required 'message' and optional 'context' parameters semantically 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 uses a specific verb ('Report') with clear resources ('bug, missing feature, or feedback'). It clearly distinguishes itself from the sibling Meta Ads tools, which are all advertising-related, making the purpose 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 provides clear context for when to use the tool: to report bugs, missing features, or send feedback. It also gives a concrete instruction to include the conversation array for reproduction, though it does not explicitly state exclusions or alternatives.

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 (readOnlyHint, idempotentHint, destructiveHint) already convey the non-mutating behavior. The description reinforces this by using 'show', which implies no side effects. No contradiction.

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 sentence that fully conveys the tool's purpose without any unnecessary 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?

Given the simplicity of the tool and absence of output schema, the description sufficiently explains what the tool returns (versions). No additional context is needed.

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

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

The tool has no parameters, so there is nothing to describe. The schema is empty and consistent.

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 clearly states the tool's function: showing current MCP platform and adapter versions. It is specific and distinguishes it from other informational tools like toolkit_info.

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 indicates the tool's purpose but does not explicitly state when to use it or when not to. Since it is a simple version retrieval tool, usage is intuitive, but explicit guidelines are absent.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds useful behavioral context by detailing exactly what data is returned, which is especially valuable given there is no output schema.

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, well-structured sentence that front-loads the action and resource, then lists the key details without redundancy or irrelevant content. Every part of the sentence adds value.

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

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

For a parameterless, read-only informational tool, the description fully covers the expected return content: installed MCPs, connection status, connected accounts, and catalog tool counts. No additional behavioral or error context seems necessary given the low complexity and clear annotations.

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?

There are zero parameters, so the schema needs no additional explanation. The description appropriately focuses on the tool's output rather than inputs, matching the baseline for parameterless tools.

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 ('Returns') and resource ('current toolkit state') while enumerating exactly what is included: installed MCPs, connection status, connected accounts, and catalog tool counts. This clearly distinguishes it from related sibling tools like 'show_version' or 'meta_ads_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?

The description implies this tool should be used to inspect overall toolkit state, but it does not explicitly state when to use it versus alternatives such as 'show_version' or 'meta_ads_status'. There are no when-to-use or when-not-to-use instructions, so the guidance is only implied.

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