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

No annotations are provided, so the description carries the behavioral disclosure burden. It explains that the URL already includes the necessary token and parameters, that the tool returns a dictionary with the next/previous page, and shows how to safely check for paging keys in a previous result. This is sufficient for a simple read-only pagination fetch.

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 one-sentence purpose, an Args section, a Returns section, and a practical Python example. Every part adds value, and the content is front-loaded with the core purpose before technical 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?

For a single-parameter pagination helper, the description covers the purpose, the source of the URL, the return type, and a realistic usage example. It also connects the tool to its sibling insights tools by referencing the paging field from a prior insights call.

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

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

Schema coverage is 0% and the schema only lists 'url' with a title. The description fully compensates by explaining the parameter is the complete pagination URL, giving concrete examples such as response['paging']['next'], and noting it includes token and 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 begins with a specific verb and resource: 'Fetch data from a Facebook Graph API pagination URL.' It clearly states the tool is for getting the next/previous page of insights API results, which differentiates it from the many insights-list siblings that fetch initial 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 clearly states when to use the tool: to retrieve the next or previous page from a prior insights API call. It does not explicitly name alternatives or exclusions, but the usage context is unambiguous and the example reinforces the intended flow.

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

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

With no annotations provided, the description carries the full behavioral disclosure burden. It goes beyond a simple read statement by noting the default one-week return window, the precedence of time_range over since/until, and the structure of the response (data and paging). These details help an agent predict behavior, although it stops short of mentioning authentication, rate limits, or error conditions, which prevents a perfect score.

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

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

The description is structured with clear sections (Args, Returns, Example) and bullet-pointed parameters, which aids scanability. It front-loads the core purpose and default behavior. The example code is lengthy but illustrates multiple use cases and pagination, earning its place. It is appropriately sized for an 8-parameter tool with no schema descriptions, so not overly verbose.

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 (8 parameters, no annotations) and the existence of an output schema, the description is remarkably complete: it covers all parameters, return structure, pagination, precedence rules, and provides multiple examples. An agent with access to this description would be equipped to call the tool correctly for common scenarios. The only omission is high-level API access requirements, but these are external to the tool's scope.

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 provides only type and title information (0% coverage), so the description fully compensates. It explains the act_id prefix requirement, enumerates available fields with descriptions and allowed values, clarifies pagination cursors, states the format of time_range, and notes precedence rules. This gives an agent complete semantic understanding beyond the schema.

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

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

The description opens with a precise verb and resource: 'Retrieves activities for a Facebook ad account.' It further clarifies scope by listing the types of changes included (account status, budget, campaign, targeting, audiences) and uses the term 'key updates to an ad account and ad objects associated with it,' which differentiates it from sibling tools like get_activities_by_adset. The purpose is unambiguous and specific.

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

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

The description implies when to use the tool (when retrieving ad account activities, with optional time ranges and pagination) through examples and parameter explanations animation. However, it does not explicitly state when to prefer this tool over alternatives (e.g., get_activities_by_adset) or provide exclusion criteria. Usage context is clear but guidance on alternatives is missing.

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

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

With no annotations available, the description carries the full burden of behavioral disclosure. It explains the default time window, that time_range overrides since/until, how pagination cursors work, and what the response shape looks like. It does not mention authentication requirements or error behavior, but for a read-only retrieval tool the disclosed behaviors are substantive and adequate.

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 long but well-structured, opening with the purpose and default behavior, then using Args, Returns, and Example sections. The parameter documentation is detailed and the examples are useful. It is somewhat verbose due to the full field enumeration, but that content earns its place given zero schema-side descriptions.

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 8 parameters, no schema description coverage, and no annotations, the description covers all necessary context: parameter semantics, default behavior, return structure, pagination, and usage examples. An agent has everything it needs to invoke the tool correctly, and the output schema covers the return type. No critical information is missing.

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

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

Schema description coverage is 0%, so the description must fully document the parameters, and it does. Every parameter is explained with types, formats, examples, and relationships (e.g., time_range overrides since/until). The fields parameter even enumerates all available field names with descriptions, adding meaning far 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 first sentence states the specific action ('Retrieves activities') and resource ('Facebook ad set'), clearly distinguishing this from account-level or campaign-level activity tools like get_activities_by_adaccount. The scope is unambiguous, and the follow-up clarifies what kind of information is returned, leaving no doubt about the tool's 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?

The description gives clear context on when to use this tool: it targets ad set activities and defaults to one week of data, with custom time ranges available. It does not explicitly name alternatives or when-not-to-use conditions, but the ad-set scoping and the sibling tool names make the usage context sufficiently clear.

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

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

No annotations are provided, so the description carries the full burden. It discloses the automatic pagination requirement, warns that some metrics may be estimated or in development, and describes the return structure. However, there is a slight internal inconsistency: it says the function 'MUST automatically fetch ALL pages' but then instructs the agent to use a separate pagination tool, which could confuse the agent about who performs pagination.

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

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

The description is long, but given the complexity (23 parameters, pagination behavior), each sentence earns its place. The structure is logical: summary, critical note, parameter list, return info, example. It is front-loaded with the critical pagination requirement, which is appropriate. A few redundant phrases could be trimmed, but overall it is well-organized.

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 and the presence of an output schema, the description covers all parameters, defaults, dependencies, and the return format. It does not mention error handling, authentication, or rate limits, but these are typically outside the scope of tool descriptions. The description is complete enough for an agent to call the tool correctly.

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

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

Schema coverage is 0%, and the description compensates fully. Every one of the 23 parameters is explained with context, defaults, examples, and override relationships (e.g., time_ranges overrides time_range and date_preset). This is comprehensive and removes any need to infer parameter meaning from the schema alone.

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

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

The description states a specific verb ('retrieves performance insights') and resource ('Facebook ad account'), and clearly differentiates from siblings like get_campaign_insights, get_adset_insights, and get_ad_insights by specifying the ad account level. It also mentions the Graph API Insights edge, making the purpose unmistakable.

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 usage guidance on automatic pagination, instructing the agent to immediately and automatically call facebook_fetch_pagination_url when paging.next exists. However, it does not explicitly state when to use this tool versus alternatives like campaign or adset insights, leaving some ambiguity for an agent selecting among 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?

There are no annotations provided, so the description takes on the full burden. It explains that it calls the Facebook Graph API, lists available fields, and mentions that a default set is returned if fields is None. This adds behavioral context (e.g., making an API call, default behavior) beyond what the schema provides.

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 detailed but well-structured: a brief summary, then bullet-list fields, and an example. It is somewhat longer than necessary but each section adds value, and the key info (purpose and fields) is 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?

Given the tool's moderate complexity (2 params, output schema present), the description covers purpose, parameters, and returns. It does not explicitly explain the return format in detail, but the output schema exists, so that is acceptable. The field list could be improved by noting that 'fields' may exclude the default fields, but overall 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%, so the description must compensate, and it does excellently. It lists and explains 20 available fields for the 'fields' parameter, and clarifies that 'ad_id' is the ID of the ad to retrieve. This goes far beyond the minimal 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 specifies the verb 'retrieves' and the resource 'detailed information about a specific Facebook ad by its ID'. It distinguishes this from sibling tools like get_ads_by_adaccount or get_ad_insights by focusing on a single ad's details.

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 states the purpose is to retrieve info for a specific ad ID, which implies when to use it versus listing tools. However, it does not explicitly exclude other tools or mention when not to use it, but the context is clear given the tool's specificity.

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

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

With no annotations provided, the description carries the full behavioral burden. It discloses that fields defaults to a standard set when None, that thumbnail dimensions default to 64x64, and that the result is a dictionary. It also makes the read-only nature clear through 'Retrieves' and 'fetch'. It does not discuss errors or rate limits, but those are less critical for a simple getter.

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 long, but the length is justified by the need to document ~30 available field values when the schema itself doesn't. It is well-structured with a clear purpose statement, parameter docs, return type, and example. Minor issue: the example calls 'get_ad_creative_details' instead of the tool's actual name, which could cause slight confusion.

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 4 parameters and no annotation coverage, the description covers everything needed to call it correctly: purpose, parameter semantics, available fields, defaults, return type, and a practical example. The output schema existence reduces the need to explain return structure further. Only explicit alternative routing is absent, which is a minor gap.

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

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

The input schema provides only parameter names with no descriptions (0% coverage), so the description fully compensates. Each parameter is explained, fields includes an extensive list of valid values with meanings, thumbnail dimensions are defined, and defaults are stated. The example further clarifies real 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 states a specific action ('Retrieves detailed information') and a specific resource ('a specific Facebook ad creative'). The 'by_id' naming plus required creative_id parameter clearly distinguishes it from sibling tools like get_ad_creatives_by_ad_id, which retrieve creatives by ad ID.

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 clearly implies this tool is for fetching a single ad creative when you have its creative_id, and lists exactly what information it returns. However, it does not explicitly call out alternatives or state when not to use this tool, so some inference is left to the agent.

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

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

No annotations are provided, so the description carries the full burden. It explains that the function accesses the Facebook Graph API, returns a dict with 'data' and 'paging', uses defaults when fields is None, and supports pagination cursors. It does not cover authentication, rate limits, or error behavior, but for a read-only retrieval this is substantially transparent.

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 long but justified by the large set of available fields and options. It is well-structured with Args, Returns, and Example sections, and the core purpose is front-loaded. The examples use the function name `get_ad_creatives` instead of `get_ad_creatives_by_ad_id`, which is a minor inconsistency.

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 6-parameter interface and lack of annotations, the description is remarkably complete: it covers all parameters, return shape, pagination, defaults, and realistic usage examples. An agent would have enough context to select and invoke the tool correctly without needing additional information.

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 compensates thoroughly. Every parameter is explained, including defaults, types, semantics for pagination cursors, date_format options, and an extensive list of valid field values with meanings. This goes well 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 states a specific action ('Retrieves the ad creatives associated with a specific Facebook ad') and identifies the resource clearly. It does not explicitly distinguish itself from the sibling `get_ad_creative_by_id`, but the plural resource and ad_id scoping make the purpose 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 clearly conveys the intended context: call this when you need creatives for a specific ad, and the examples show typical invocation patterns with fields and pagination. It does not explicitly say when not to use it or mention alternatives, but the context is unambiguous.

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

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

No annotations exist, so the description carries the full burden. It compensates well by making the read-only nature clear through the verb 'List,' exposing the default field set, documenting cursor-based pagination and filtering, and stating the return container. It does not discuss auth or rate limits, which is acceptable for a straightforward read/list operation.

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

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

The purpose statement is front-loaded, followed by a tight argument list and a one-line return note. There is no fluff or repetition of schema metadata; every sentence adds information.

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

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

For a six-parameter tool with no annotations, the description is nearly complete: all parameters are documented, defaults are given, and an act_id example is provided. It omits high-level selection guidance relative to the many sibling tools, but an agent can construct a valid call from this description alone.

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, and the description fully compensates: it explains act_id with an example, enumerates available fields and the default, defines limit, clarifies 'after' and 'before' as pagination cursors, and describes the hashes filter. Every parameter receives meaningful semantic 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 opens with a clear, specific action and resource: 'List images in the ad account's creative library.' 'List' plus 'images' makes the operation unambiguous, though it does not explicitly contrast this tool with sibling tools like get_ad_creatives_by_ad_id or get_ad_creative_by_id.

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 given on when to use this tool versus sibling tools, nor are there any exclusions or alternative suggestions. The argument documentation implies it is for image metadata, but an agent receives no help deciding between this and the creative-oriented siblings.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It goes beyond a simple retrieval statement by noting 'some metrics may be estimated or in development', documenting parameter precedence (e.g., 'Overrides date_preset', 'Ignored if time_ranges is provided'), and revealing default dependence on API/settings for attribution windows. It does not mention auth requirements, rate limits, or error conditions, but the behavioral traits it does cover are material and useful.

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 long, but the length is justified by the 23 parameters and zero schema coverage. It is front-loaded with a two-sentence summary before diving into Args, and the Returns and Example sections are functional. Every section earns its place; the only slight deduction is that the Args list could tighten a few repetitive default statements without losing 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 23-parameter tool with no annotations, the description is remarkably complete: it covers all parameters, return shape, example usage, pagination handling, and an important caveat about metric reliability. An agent has enough information to call the tool correctly and to chain pagination with the sibling fetch_pagination_url tool. The presence of an output schema also offsets the need to describe return values in more detail.

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 must fully compensate. It does so exceptionally: every one of the 23 parameters is explained with type, default, examples, and precedence relationships. The fields parameter even lists many common metric strings. This adds substantial meaning beyond the bare schema and is the strongest aspect of the definition.

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

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

The description opens with a specific verb and resource: 'Retrieves detailed performance insights for a specific Facebook ad' and repeats 'individual ad (ad group)' in the second line. This clearly distinguishes it from sibling insight tools like get_campaign_insights, get_adset_insights, and get_adaccount_insights, which operate at different levels of aggregation. The tool's purpose is unambiguous.

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

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

The description provides clear context for when to use the tool: when performance metrics are needed for a single ad, not an account, campaign, or ad set. It does not explicitly name alternative tools or state when not to use this one, but the entity scope ('specific Facebook ad', 'individual ad') is clear enough for an agent to select it correctly among the sibling insight tools. There are no explicit exclusions, so it falls short of a 5.

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

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

No annotations are provided, so the description carries the full burden. It states the return type and field defaults, which is helpful. However, it does not clarify pagination, what a null limit means, or explicitly state that this is a read-only operation, and 'List all' sits awkwardly with the limit parameter.

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

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

The description is front-loaded with a single-sentence purpose followed by compact Args and Returns sections. Each parameter gets one clear line, and there is no filler or redundant information.

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

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

For a simple three-parameter read/list tool with an output schema present, the description covers the essentials: purpose, accepted parameters, and return shape. The main gaps are the missing pagination/null-limit semantics and lack of usage guidance, but the tool is otherwise callable from the provided text.

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%, but the description compensates well: act_id includes an example format, fields enumerates all available values and the default, and limit explains maximum result count. It adds meaningful semantics beyond the raw schema, though null limit behavior could still be clearer.

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—'List'—and a clear resource, 'ad labels', with the scope 'in an account'. It also explains what ad labels are for, which adds context. However, it does not explicitly differentiate itself from sibling tools, though no sibling appears to cover the same 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?

The description gives no guidance on when to use this tool versus alternatives, no exclusions, and no prerequisites. The phrase 'used for organizing campaigns, ad sets, and ads' implies a use case, but the agent is left to infer when this tool 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?

With no annotations, the description carries the burden of behavioral disclosure. It does clarify the return shape (a dictionary with lead submissions and pagination info) and documents field defaults. However, it does not mention auth requirements, rate limits, errors, or what happens when an ad has no lead form, leaving some behavior implicit.

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 with a clear purpose and then organized into Args/Returns sections. It is longer than a one-liner, but every line adds information the schema omits, so the length is fully justified and there is no filler.

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

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

For a 5-parameter tool with no annotations, the description covers all parameters, defaults, and return shape, and an output schema is present. Missing usage context and edge-case behavior are the only notable gaps, but the agent has enough to call the tool correctly.

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

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

Schema description coverage is 0%, but the description fully compensates by documenting all five parameters. It lists the valid field names, the default field set, the meaning of limit, and the direction of after/before cursors. This is essential meaning the schema alone lacks.

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

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

The first sentence names a specific operation and resource: 'Get lead form submissions for a Lead Generation ad.' This is concrete and distinct from sibling tools like get_ad_insights or get_ad_creatives, which retrieve different data for the same ad. 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?

The description gives no guidance on when to choose this tool over alternatives or when not to use it. It only says it operates on a Lead Generation ad, which is implicit context rather than explicit selection criteria.

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

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

With no annotations, the description carries the full burden. It does disclose the read-only nature ('Get'), the return shape ('A dictionary containing preview iframe data'), and the all-placements behavior when ad_format is None. However, it omits error behavior, permissions, and edge cases, so transparency is only partial.

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

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

The docstring-style layout front-loads the one-line purpose and uses compact, scannable Args and Returns blocks. The long placement enum is justified because the schema lacks an enum, and there is 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?

All three parameters are explained, the return type is stated, and an output schema exists so return documentation is optional. Remaining gaps are the lack of valid field-name enumeration, error-condition behavior, and usage guidance relative to the many sibling retrieval tools.

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

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

Schema description coverage is 0%, but the description compensates fully: it explains ad_id, ad_format with a concrete placement list and default behavior, and fields with an example. This adds real meaning beyond the bare schema types and defaults.

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

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

The first sentence states a specific verb and resource: 'Get preview iframes for an ad across different placements.' This clearly distinguishes it from siblings like get_ad_creative_by_id or get_ads_by_adaccount, which retrieve creative content or ad lists rather than iframe previews.

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 instead of alternatives; the only contextual note ('If None, returns all available') describes ad_format behavior, not tool selection. No siblings are named and no exclusions or prerequisites are mentioned.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the return type ('A dictionary') but does not state that the operation is read-only, does not discuss error behavior, authentication requirements, rate limits, or any side effects. The 'Get' verb implies read-only, but the description does not explicitly disclose this or other behavioral traits.

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

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

The description is well-structured with an Args/Returns format, front-loads the purpose, and contains no redundant sentences. Every sentence provides useful information, making it easy to parse.

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

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

Given that an output schema exists, the description does not need to explain return structure in detail. It covers all parameters with necessary semantics and the return type. However, it omits any mention of error conditions or constraints (e.g., max limit), which would be helpful but not strictly required. Overall, it is sufficiently complete for an agent to call the tool correctly.

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

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

Schema description coverage is 0%, so the description must compensate, and it does thoroughly. It explains each parameter: rule_id, fields (with available values and default), limit, after, and before (pagination cursors). This adds significant meaning beyond the bare schema definitions.

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 purpose: 'Get the execution history of an automated ad rule — what actions it has taken and when.' It names the specific resource (ad rule history) and the action (get), and it is distinguishable from siblings like get_ad_rules which fetch rules themselves, not their history.

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

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

The description provides no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. While the purpose implies its use case, there is no explicit routing or context to help an agent decide between this and other tools.

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

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

With no annotations provided, the description carries the behavioral burden and does a reasonable job: 'List' signals a read-only operation, and it documents defaults, pagination cursors, and the return shape. It does not dwell on error conditions or rate limits, but none are 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 compact, well-structured with an Args block, and front-loads the core purpose before parameter details. Every line contributes useful information with no filler.

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

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

For a simple list operation with an output schema, the description supplies all parameters, defaults, and return type needed to call the tool. It lacks only alternative-selection context, but that gap is already reflected in usage_guidelines.

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 fully compensates: act_id gets a format example, fields enumerates valid values and defaults, limit is defined, and after/before are labeled as forward/backward pagination cursors.

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 clear verb and resource: 'List all automated ad rules configured for an ad account', with concrete examples. It is unambiguous, though it does not explicitly contrast with sibling tools such as get_ad_rule_history.

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 prefer this tool over alternatives or when not to use it. Siblings like get_ad_rule_history are not mentioned, leaving the selection decision entirely to the agent.

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

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

With no annotations, the description carries full responsibility for behavioral disclosure. It does this well: it explains the return structure (data list and paging object), pagination via after/before cursors, filtering semantics, and the default set of fields. It does not mention permissions or rate limits, but for a read-only retrieval operation the disclosed behavior 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 lengthy, but every section earns its place given 10 parameters. It is logically structured (summary, Args, Returns, Example) and front-loaded with the core purpose. The extensive field list is arguably verbose, but for an agent this is valuable reference material. Only minor trimming could improve 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?

This is a 10-parameter tool with no schema description coverage and no annotations, yet the description covers all parameters, the return format, pagination, and provides a complete example with next-page handling. The presence of an output schema means the description need not detail return fields, and it does not. Nothing an agent needs to invoke this tool correctly is missing.

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

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

Schema description coverage is 0%, so the description must fully compensate. It does: every parameter is explained with types, formats, defaults, and even common values (e.g., effective_status options, field list). The act_id 'act_' prefix, the filter object structure, and pagination cursor usage are all clearly defined. This is exemplary 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 opens with a clear verb–resource pair: 'Retrieves ads from a specific Facebook ad account.' It explicitly narrows the scope to a single ad account, which distinguishes it from sibling tools like get_ads_by_campaign and get_ads_by_adset. The purpose is unambiguous and cannot be confused with others in the same family.

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

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

The context of use is clear — when you need ads by ad account, not by campaign or adset. However, the description never explicitly says 'use this instead of X' or mentions alternatives. It relies on the reader to infer the appropriate scenario from the scope statementaint; no explicit when-not-to-use guidance is given.

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

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

No annotations are provided, so the description carries the full burden. It discloses pagination behavior (cursors, limit, before/after), default field behavior, date format options, and effective status filtering. It also explains the return structure (data list, paging object). This is substantial behavioral context beyond the schema. It doesn't mention rate limits or auth requirements, but for a read operation this is adequate.

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 clear sections (Args, Returns, Example) and front-loads the core purpose. It is somewhat long due to the comprehensive parameter documentation and examples, but every section earns its place. The examples are useful but could be trimmed to one to reduce length. Overall, it's organized and scannable.

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 (8 parameters, pagination, filtering, multiple date formats), the description is complete. It covers all parameters, return structure, pagination flow, and provides a working example. The output schema exists, so return values are further documented. An agent has everything needed to call this tool correctly without additional inference.

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 fully compensate. It does: every parameter is explained with types, defaults, options, and examples. The filtering parameter gets detailed operator lists, date_format gets explicit format strings, and pagination parameters reference the response structure. The example usage demonstrates real parameter combinations. This is exemplary compensation for a schema with no 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 clearly states the tool retrieves ads associated with a specific Facebook ad set, with a specific verb ('Retrieves') and resource ('ads...ad set'). It distinguishes itself from siblings like get_ads_by_campaign and get_ads_by_adaccount by explicitly scoping to adset_id. The title and description align, and the resource 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?

The description provides clear context for when to use this tool: when querying ads belonging to a specific ad set. It includes filtering, pagination, and field selection guidance. However, it does not explicitly state when NOT to use it or name alternatives like get_ads_by_campaign or get_ads_by_adaccount, which would strengthen the guidance. The example showing pagination usage is helpful.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It explains pagination cursors, default limit, how filtering works, and the response structure. It does not mention error behavior, rate limits, or auth requirements, but for a read-only retrieval tool the disclosed behavior is substantial and accurate.

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 organized in clear sections: a one-line purpose, an args list with precise detail, a returns line, and a practical example. Nothing is redundant; the length is justified by the density of useful information. The example demonstrates both basic use and pagination without 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 7-parameter tool with no annotations ret and no visible output schema, this description covers purpose, all parameters, return format, and common usage patterns. The pagination example is particularly valuable. An agent has everything needed to call this tool correctly.

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

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

Schema description coverage is 0%, so the description must fully compensate. It does: every parameter is explained with types, defaults, and options. The 'fields' parameter lists common field names, 'effective_status' enumerates allowed values, and 'after'/'before' explicitly state they come from the paging cursor. This far exceeds what the bare schema provides.

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

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

The description opens with a specific verb and resource: 'Retrieves ads associated with a specific Facebook campaign.' This unambiguously distinguishes it from siblings like get_ads_by_adset and get_ads_by_adaccount by naming the campaign scope, so an agent can immediately identify what this tool does.

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 clearly establishes the context: use when you have a campaign_id and need its ads. It explains filtering, pagination, and field selection with a worked example, implying the appropriate use case. It does not explicitly name alternatives or exclusions, so it misses the fifth point by not stating 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?

No annotations are provided, so the description carries the burden. It discloses that it accesses the Facebook Graph API, that fields is optional with a default set returned, and that the return is a dictionary. It also documents deprecated fields (status) and field options. However, it doesn't disclose potential errors (e.g., invalid ID, permission failures), rate limits, or whether the default field set is comprehensive. The behavior is mostly transparent for a read operation, but some operational details are missing.

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 long and detailed, but the field list is necessary given 0% schema coverage. The structure is clear: overview, args, returns, examples. However, it is somewhat verbose—the field list could be trimmed or moved to the schema, and the repeated enum options add bulk. It earns a 3 because it's well-organized but not tightly concise.

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 (2 params, one with a huge field list) and no annotations, the description covers the essential context: what it does, what parameters mean, what it returns, and examples. It doesn't cover error handling or permission requirements, but for a read-only retrieval tool with an output schema, it is largely complete. The output schema exists, so return values are further 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 description coverage is 0%, so the description must fully compensate. It does: adset_id is explained as 'The ID of the ad set to retrieve information for', and fields is explained in depth with a list of ~40 available fields, their meanings, and enum options. The examples show realistic usage. This is far beyond what the bare schema provides.

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

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

The description clearly states the tool retrieves detailed information about a specific Facebook ad set by its ID, naming the resource (ad set) and the action (retrieve). It distinguishes itself from sibling tools like get_adsets_by_ids (plural) and get_adset_insights (insights) by focusing on a single ad set's detailed fields. The verb 'retrieves' is specific and the resource 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?

The description explains the tool accesses the Facebook Graph API to retrieve a single ad set's details, and the examples show typical use cases (basic info, scheduling info). It doesn't explicitly state when NOT to use it or name alternatives, but the context of 'by ID' and the sibling list (e.g., get_adsets_by_ids, get_adsets_by_adaccount) makes the usage context reasonably clear. It lacks explicit exclusions or alternative routing.

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

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

With no annotations provided, the description carries the behavioral disclosure burden and does a solid job: it states the return shape ('data' and 'paging' keys), explains parameter precedence and overrides, documents defaults, and warns that 'some metrics may be estimated or in development.' It doesn't cover authentication or rate limits, but those are less critical for a read-only insights retrieval.

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 long, but the length is justified by 23 parameters and no schema-level descriptions. It is well structured with a front-loaded summary, Args list, Returns, and Example. Some minor imprecision remains, such as 'etc.' in date_preset and breakdowns, but there is no fluff.

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-complexity tool with 23 parameters, no annotations, and no schema descriptions, the description covers purpose, every parameter, defaults, precedence, output shape, pagination, and a working example. It could be more complete with exact enum values and explicit notes on permissions or rate limits, but it is already sufficient for correct invocation in most cases.

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, but the Args section fully compensates by documenting all 23 parameters with types, defaults, examples, and precedence relationships (e.g., time_ranges overrides time_range, which overrides date_preset). It even provides concrete field examples and pagination cursor semantics, going well 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 opens with a precise verb and resource: 'Retrieves performance insights for a specific Facebook ad set.' It also clarifies the analytical scope ('metrics across its child ads'), which distinguishes it from sibling tools like get_ad_insights or get_adaccount_insights without needing to open any schema.

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

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

Usage is implied by the resource name and the statement about analyzing metrics across child ads, and the example demonstrates a typical call. However, there is no explicit guidance on when to choose this tool over sibling insights tools, nor any exclusions such as 'for account-level metrics use get_adaccount_insights instead.'

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

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

With no annotations provided, the description carries full behavioral burden, and it delivers: it documents default field behavior, default and maximum pagination limits, cursor usage, date format options, status filters, and the response shape in 'data' and 'paging'. It also demonstrates pagination with a concrete example, which is exactly the kind of runtime behavior an agent needs.

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?

Although long, the description is structured into summary, Args, Returns, and Example, and every section earns its place given 11 parameters and no enum support in the schema. The one-sentence purpose is front-loaded, and the examples are functional rather than filler.

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

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

For a read-style list operation with 11 parameters, the description leaves little unexplained: all parameter semantics, return structure, pagination flow, and a full usage pattern are included. With an output schema present and no annotations, this is as complete as an agent needs to invoke it correctly.

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

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

Schema description coverage is 0%, and the description compensates fully: act_id prefix format, fields default semantics, filtering operator list with an example, limit default/max, pagination cursor provenance, date_preset options, time_range format, updated_since units, effective_status options, and date_format choices are all spelled out. This goes far beyond the bare parameter titles in the schema.

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

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

The description opens with a specific verb and object: 'Retrieves ad sets from a specific Facebook ad account,' and clarifies the scope as 'all ad sets belonging to a specific ad account.' This scope separates it from sibling tools like get_adsets_by_campaign or get_adset_by_id, even though those siblings aren't named.

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 clearly states the tool is for querying all ad sets by ad account, with filtering, pagination, and field selection. It does not explicitly name alternatives or state when not to use it, but the ad-account-scoped context is clear enough for an agent to select it over campaign/id-based variants.

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

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

With no annotations, the description carries the full behavioral burden and does so well: it explains default field behavior, filter object structure and operators, pagination cursors, effective_status options, date formats, and the response envelope. It doesn't address auth, rate limits, or errors, but the read-only retrieval nature and response shape are disclosed clearly enough.

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 long but well organized: purpose first, then Args, Returns, and a multi-scenario Example section. Every section earns its place, though the text could be tightened without losing critical 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?

For an 8-parameter tool with no annotations, the description is effectively self-contained: every parameter is explained, the return structure ('data' and 'paging') is specified, and examples cover basic queries, filtering, and pagination. Referencing get_adset_by_id for the full field list is an appropriate pointer rather than a gap.

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

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

The input schema has 0% description coverage and no enums, yet the description fully documents all eight parameters, including defaults, the 25/100 limit, filter object requirements, available operators, pagination source fields, status options, and date format choices. This adds substantial meaning that the schema alone completely lacks.

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

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

States a specific verb ('Retrieves') and resource ('ad sets associated with a specific Facebook campaign'), and the campaign scoping is unambiguous. It doesn't explicitly compare itself to sibling tools like get_adsets_by_adaccount or get_adsets_by_ids, so differentiation is mostly left to the name and required parameter.

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 clearly implies usage: pass a campaign_id to get that campaign's ad sets, and the examples demonstrate realistic filtering and pagination workflows. However, it never states when to prefer this tool over account-level or single-ad-set siblings, and there are no explicit exclusion criteria.

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

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

No annotations are provided, so the description carries the full burden. It discloses the read-only nature ('Retrieves') and explains return format and date formatting, but it doesn't mention authentication, rate limits, pagination, or behavior on invalid IDs. For a retrieval tool this is adequate but not comprehensive; it adds some value beyond the name, but significant behavioral context is missing.

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 longer than average but well-structured with Args, Returns, and a full example. Every sentence serves a purpose—the example is useful for showing calling conventions and response access. While it could be trimmed slightly, the structure is logical and information-dense, so it earns its length.

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 (batch retrieval, optional fields, date formatting), the description covers all parameters, the return structure, and a working example. It does not mention edge cases like partial failures or pagination, and the output schema is not shown, but the description does explain the dict format. This is nearly complete for an agent to call correctly, with minor gaps around error behavior.

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

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

Schema coverage is 0%, so the description must fully explain each parameter. It does so thoroughly: adset_ids is clearly the list of IDs, fields is explained with default behavior and a pointer to get_adset_by_id for full options, and date_format lists all supported values ('U', 'Y-m-d H:i:s', None) with their meanings. The example demonstrates realistic usage, adding clarity beyond the schema.

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

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

The description states a specific action ('Retrieves detailed information'), a precise resource ('Facebook ad sets'), and a specific scoping constraint ('by their IDs'). It also highlights the batch nature, clearly distinguishing it from singular and account/campaign-based siblings like get_adset_by_id and get_adsets_by_adaccount. No ambiguity remains.

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 when you have specific ad set IDs and need batch efficiency, but it does not explicitly contrast this with alternatives. For example, it doesn't say 'Use this when you have exact IDs; use get_adsets_by_adaccount when you want all adsets for an account.' The only reference to a sibling is for field lists, not for selection guidance. This is implied 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states the tool 'retrieves' information via the Facebook Graph API, implying a read-only operation with no side effects. It also details how fields and date_format affect output, including default behaviors. It does not mention error handling or rate limits, but for a straightforward GET operation this is acceptable; the description is transparent about what the tool does and does not do.

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 long, but it is well-structured with a purpose statement, Args section, Returns note, and a full example. The extensive field enumeration is justified because the schema provides no descriptions, making it essential for correct field selection. Every section serves a purpose, and the organization makes it easy to scan. It is appropriately thorough rather than bloated.

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 (many optional fields and a date format option), the description is complete. It covers all parameters, their defaults, allowed values, and gives a concrete example. Since an output schema exists, it does not need to describe the return structure beyond stating it returns a dict. No critical information for invoking the tool correctly is missing.

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

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

Schema description coverage is 0%, so the description must compensate fully. It does: it explains every parameter in detail—campaign_id with its role, fields with a comprehensive list of valid values and their meaning, and date_format with all allowed formats. Examples further clarify usage. This is far beyond minimal and gives an agent everything needed to construct correct arguments.

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

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

The description opens with a specific verb and resource: 'Retrieves detailed information about a specific Facebook ad campaign by its ID.' This clearly states the tool's function and distinguishes it from sibling tools like get_ad_by_id or get_adset_by_id, which target different entities. The purpose is immediately actionable.

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?

While the description does not explicitly list when to use this tool over alternatives, it imposes clear context: this is for a single campaign identified by ID, which naturally separates it from tools that list campaigns or handle other entities. The absence of exclusions or direct sibling comparisons is compensated by the specificity of the function name and description, giving an agent sufficient 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?

With no annotations available, the description carries the full burden of behavioral disclosure. It does extensively: covers parameter precedence (e.g., time_range overrides date_preset), defaults, pagination behavior via after/before/offset, and the return shape with 'data' and 'paging' keys. The example even demonstrates fetching the next page. This is far beyond minimal disclosure.

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 long but structured into clear sections: summary, Args, Returns, and an Example. Every paragraph earns its place given the large parameter count. The core purpose is front-loaded, and the example provides practical usage context without redundancy.

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-complexity tool with 23 parameters, no annotations, and an output schema, the description is essentially complete. It covers all parameters, defaults, precedence rules, return format, pagination, and an invocation example. Nothing an agent needs to call the tool correctly is missing.

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

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

Schema description coverage is 0%, so the description must compensate for all 23 parameters. It does so thoroughly: each parameter has an explanation, common values, defaults, and precedence relationships. For example, date_preset lists all valid options and notes when it is ignored, and time_increment explains integer vs 'monthly'/'all_days' behavior. This adds substantial 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 opens with a specific verb and resource: 'Retrieves performance insights for a specific Facebook ad campaign.' It clearly states the tool fetches statistics for a given campaign ID and lists representative metrics. This differentiates it from sibling tools like get_ad_insights or get_adaccount_insights by anchoring to campaign_id.

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: use this for performance insights on a specific campaign, with campaign_id required. However, it does not explicitly mention alternatives or exclusions, such as 'for ad-account-level insights use get_adaccount_insights.' The level parameter also creates some overlap with adset/ad insight tools, but the intent is still clear enough for correct selection.

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

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

No annotations are provided, so the description carries the full burden. It discloses pagination via after/before cursors, default limit (25) and max (100), default field behavior (None returns default set), date formats, filtering operator syntax, and example response structure. It also shows how to handle pagination in the example. It does not mention authentication, rate limits, or error conditions, but given the complexity it covers most critical behavioral aspects.

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 long but warranted given 16 parameters. It uses a clear Args/Returns/Example structure, with parameters grouped logically and examples that illustrate common usage patterns. It is not tautological or padded; each sentence adds value. It could be slightly tighter, but the structure aids readability and is appropriate for the tool's complexity.

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 16 parameters, an output schema, and is part of a large sibling family, the description is remarkably complete. It covers every parameter's semantics, default behaviors, valid enum values, pagination workflow, and even shows chained pagination in the example. The output schema (not shown in description but present) handles return structure; the description complements it by explaining where data and paging live. Nothing essential for calling this tool correctly is missing.

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

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

Schema description coverage is 0%, so the description must compensate, and it does thoroughly. Every parameter is documented with its type, purpose, defaults, and often a list of valid values (e.g., date_preset options, effective_status options, objective options). The filtering parameter includes operator enums and a concrete example. The time_range and date_format have clear examples. This far exceeds schema-only information.

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

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

The description opens with a specific verb+resource: 'Retrieves campaigns from a specific Facebook ad account.' It clearly states the tool's scope (all campaigns of one account) and differentiates itself from single-resource tools like get_campaign_by_id, which is explicitly referenced for field lists. An agent can immediately understand what this does and how it differs 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 gives clear context: it's for querying campaigns by ad account, with filtering and pagination. It explicitly points to get_campaign_by_id for the comprehensive field list, signaling that this tool is for bulk/listing queries. The example shows how to fetch the next page, implying when pagination is needed. However, it doesn't explicitly state 'use this when you need multiple campaigns and get_campaign_by_id for a single one,' leaving that to inference.

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

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

No annotations are provided, so the description carries the disclosure burden. It does disclose the read-only nature via 'List', documents pagination cursors, available fields with defaults, and the return shape. However, it omits permission requirements, error behavior, and any caveats about pagination or result limits.

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

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

The purpose is front-loaded in the first sentence, and the argument documentation is organized into a clean, scannable list with defaults and return information. There is no filler or redundant restatement 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 read-only list tool with 5 parameters and an output schema, the description covers the operation, all parameter meanings, defaults, and the return value. It is missing only explicit routing guidance relative to sibling audience-related tools and any behavioral caveats.

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 fully compensate. It does: act_id is given with an example, fields are enumerated with a default list, limit is defined, and after/before are described as forward and backward pagination cursors. Every parameter receives meaningful semantic 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 names a specific verb and resource: 'List all custom audiences for an ad account', and gives illustrative categories like CRM uploads, pixel-based, and lookalikes. It is clear about scope, but it does not explicitly distinguish itself from sibling tools such as get_saved_audiences, leaving some ambiguity among audience-related 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?

There is no guidance on when to use this tool versus alternatives like get_saved_audiences or get_pixels, and no stated exclusions or prerequisites. The description focuses entirely on arguments and return value, so it provides no decision support for tool selection.

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

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

With no annotations provided, the description carries the behavioral burden. It explains that this is a list operation, documents the default fields returned, defines pagination cursor semantics, and states the return type as a dictionary. Minor gaps remain around authentication, rate limits, and whether 'all' implies full pagination, but the read-only nature 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 well-structured with a concise purpose line, grouped Args, and a Returns section. The parameter details are dense but relevant, with no filler or redundant restatement of the schema.

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

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

For a listing tool with one required parameter and an output schema available, the description covers the essential invocation details: required ID format, optional fields, pagination controls, and return type. It could additionally explain how to iterate pages to retrieve 'all' conversions, but the provided cursors and return-type note make it sufficiently 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 input schema has 0% description coverage, so the description must compensate—and it does. Every parameter is explained: act_id includes a concrete example, fields lists valid options and its default, limit defines its purpose, and after/before are clearly identified as pagination cursors.

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

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

The description opens with a specific verb and resource: 'List all custom conversions defined for an ad account.' This clearly distinguishes the tool from sibling tools like get_custom_audiences and get_saved_audiences by naming the exact object type, scope, and 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 intended use is implied by the resource name and the phrase 'defined for an ad account,' but the description does not explicitly state when to choose this tool over alternatives. No exclusions, conditions, or sibling comparisons are provided, so the agent must infer usage from the tool name and purpose.

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

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

With no annotations provided, the description carries the full behavioral disclosure burden. It does state the return contract ('dictionary containing daily_outcomes_curve') and that the metrics are projections. It does not mention error conditions, permissions, rate limits, or side effects, though the 'Get' verb implies a read operation.

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, with a single purpose sentence followed by a concise Args/Returns list. Every sentence contributes useful information, and examples are woven in without redundancy. There is no filler or repetition of schema fields.

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

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

For a three-parameter read-only estimation tool with no annotations, the description covers the essential invocation needs: what it does, how to pass each parameter, and what to expect back. The main gaps are lack of explicit routing against sibling tools like get_reach_estimate and absence of error/edge-case expectations, but the core call is fully navigable.

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 itself, and it does so well. adset_id is given a clear role, optimization_goal is defined as an override with concrete examples, and promoted_object includes a JSON example. This is strong compensation for an otherwise 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 opens with a specific verb and resource: 'Get projected delivery metrics ... for an existing ad set.' It clearly states what is returned (estimated daily reach and impressions) and the target entity. It does not explicitly distinguish itself from the sibling get_reach_estimate, so it stops just short of top marks.

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 context by saying the tool operates on an existing ad set and supports an optimization_goal override. However, it does not state when to prefer this tool over alternatives such as get_reach_estimate, nor does it give any when-not-to-use guidance. Usage is therefore only implied, not explicit.

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

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

No annotations are provided, so the description carries the burden. It discloses the return type ('A dictionary'), the default behavior for fields, and the read-only nature implied by 'Get'. However, it does not mention permissions, error cases, or behavior for invalid act_id.

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

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

The description is a clean docstring with front-loaded purpose, followed by Args and Returns. The field list is lengthy but necessary given the schema's lack of descriptions, and every sentence earns its place.

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

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

For a low-complexity getter with one required parameterfixed, this description covers what the tool does, both parameters, default behavior, and return type. Given the output schema also exists, nothing essential is missing for selecting and invoking the tool correctly.

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

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

Schema description coverage is 0%, but the description fully compensates by documenting act_id with an example and explaining fields, including the default behavior and an enumerated list of available fields. This adds substantial 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?

States a specific verb ('Get') and resource ('ad account'), and clarifies it's for a specific account, distinguishing it from list_ad_accounts and get_adaccount_insights. 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?

The description clearly implies use when you have a specific act_id and want detailed fields for that account. It does not explicitly name alternatives or exclusions, but the 'specific ad account' framing provides sufficient context among the many sibling getters.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. It correctly implies a read-only retrieval and says a dictionary is returned, but it does not disclose default/null behavior, error conditions, account-permission needs, or rate-limit expectations.

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

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

The purpose is front-loaded, and the Args/Returns section is compact with no wasted words. Every sentence adds useful information for calling the tool.

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

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

For a simple 2-parameter getter with an output schema, the essential call contract is covered: purpose, required act_id, optional bid_strategy, and return shape. A note on omitted bid_strategy behavior would make it 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?

Schema description coverage is 0%, but the description compensates by explaining act_id with a concrete act_1234567890 example and listing realistic bid_strategy values. The only gap is not explicitly stating what happens when bid_strategy is null, though the schema default helps there.

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

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

States a specific verb and resource: 'Get the minimum daily budget requirements for different campaign objectives and bid strategies.' This clearly distinguishes it from sibling getters by naming the exact budget-related resource and the dimensions it covers.

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

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

No when-to-use guidance or comparison to alternatives is provided. The description does not clarify how this relates to sibling tools like get_reach_estimate or get_delivery_estimate, nor does it state a preferred selection 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?

With no annotations provided, the description carries the full behavioral burden. It does disclose the required permission (pages_read_engagement) and the return shape (a dictionary), which is helpful. However, it omits known behavioral constraints of the Facebook Insights API, such as metric/period compatibility restrictions, rate limits, and error behavior when the page is inaccessible or permissions are missing.

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 with the core purpose, then the permission note, then a compact Args/Returns reference. The parameter list is lengthy but fully justified because schema description coverage is 0%—every entry provides information the agent cannot obtain elsewhere. Nothing is wasted, though the formatting could be tightened slightly.

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 6-parameter tool with zero schema coverage and no annotations, the description covers the essentials: all parameters, valid values, and permission. However, it misses practical Facebook API failure modes an agent would hit: metric/period incompatibility (e.g., some metrics reject the lifetime period) and the typical exclusivity between date_preset and since/until. These gaps could cause avoidable errors.

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

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

Schema description coverage is 0%, so the description must compensate, and it does comprehensively. Every one of the 6 parameters is documented: page_id, metric (with 10 enumerated common values), period (with 5 valid values), date_preset (with examples), and since/until (with both UNIX timestamp and YYYY-MM-DD formats). This adds decisive value the input schema alone does not provide.

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?

"Get performance insights for a Facebook Page" is a specific verb+resource statement, and the enumerated metric list (page_impressions, page_reach, page_engaged_users, etc.) makes the scope unambiguous. An agent can immediately distinguish this from sibling insight tools targeting other resources (get_adaccount_insights, get_campaign_insights, get_ad_insights) and from get_page_posts/get_promotable_posts, which concern post content rather than analytics.

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

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

The description provides no explicit when-to-use guidance or exclusions relative to its siblings. It never states 'use this for Page-level analytics rather than ad/campaign insights' or notes when it should not be used; the only contextual hint is the pages_read_engagement permission prerequisite. The intended usage must be inferred entirely from the metric names.

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

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

With no annotations, the description must disclose behavior. It does mention the required permission (pages_read_engagement) and pagination semantics (after, before, since, until), but does not cover rate limits, error handling, or what happens on invalid page_id. It also states the return shape as a dictionary, but not deeply. This is adequate but not comprehensive.

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: purpose and permission are front-loaded, followed by a clear Args list and a brief Returns note. It is a bit long but every sentence earns its place given the number of parameters. No fluff.

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 7-parameter read tool with an output schema (not shown but referenced), the description covers all inputs, the permission requirement, and a high-level return summary. It lacks details on error behavior or rate limits, but these are often secondary for a read operation. Overall, it gives an agent enough to call 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 fully explain each parameter. It does so thoroughly: page_id, fields with a detailed list and defaults, limit, pagination cursors, and date filters with format hints. This significantly adds meaning beyond the bare schema, which only has types and null defaults.

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

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

The description states a specific verb ('Get') and resource ('published posts from a Facebook Page'), clearly distinguishing it from siblings like get_page_insights and get_promotable_posts. It leaves no ambiguity about what the tool does.

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. It does not mention exclusions or conditions that would route an agent to a different tool (e.g., get_promotable_posts for boosted content). The usage context is only implied by the tool's name and description.

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

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

No annotations are provided, so the description carries the full burden. It states 'List all' but includes a limit parameter, which creates ambiguity about whether the result set is truly all pixels. It also does not disclose whether this is a read-only operation (though 'List' implies it), nor does it mention pagination, rate limits, or any side effects. The return type is described, but behavioral nuances are missing.

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 an Args/Returns format, the purpose is front-loaded, and it is concise. Each sentence adds value, though the formatting could be tightened, but it is efficient overall.

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 output schema exists (though not shown), the description need not detail return structure extensively, and it does state the return type. However, it does not address pagination or clarify the 'all' versus limit ambiguity, nor does it mention any prerequisites or permissions. For a simple list tool, this is adequate but not 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% description coverage, but the description compensates thoroughly. It explains act_id with an example, lists all available fields for the fields parameter with a default, and defines limit as a maximum result count. This adds significant meaning beyond the schema's bare type definitions.

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 lists all Meta Pixels associated with an ad account, with a specific verb and resource. It does not explicitly differentiate from sibling tools, but the resource (pixels) is unique and the scope is clear.

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

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

The description implies usage when pixels are needed for a given ad account, and it clearly requires an act_id. However, it does not mention alternatives, when not to use it, or any exclusion criteria. The context is clear but no guidance on selecting this over other list 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?

No annotations are provided, so the description carries the behavioral burden. It discloses the required pages_read_engagement permission, the default field set, and pagination semantics for after/before. This gives meaningful operational context beyond the basic 'get' action.

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 purpose sentence, permission note, labeled Args section, and Returns section. The field list is necessary because the schema has no descriptions, so every sentence earns its place.

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

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

For a 5-parameter tool with no annotations, the description is complete: it covers the required permission, all parameters, defaults, available fields, pagination behavior, and return type. The output schema can carry the detailed return structure, so nothing essential is missing.

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

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

Schema description coverage is 0%, but the description fully compensates by explaining every parameter: page_id, fields with allowed values and defaults, limit, and forward/backward pagination cursors. This is far more than the schema provides.

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

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

States a specific verb and resource: 'Get organic Page posts that are eligible to be boosted as ads.' The eligibility qualifier clearly distinguishes it from sibling tools like get_page_posts and other read-only retrieval 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?

The purpose implies when to use it, and the permission requirement gives a prerequisite, but there is no explicit guidance on when to prefer this over get_page_posts or other sibling tools. The usage context is clear but not directly contrasted with 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?

With no annotations provided, the description carries the full behavioral burden. It discloses that the tool returns a dictionary with users_lower_bound and users_upper_bound, that optimization_goal affects the estimate, and that currency defaults to the account currency. The word 'estimate' and the 'before creating' framing imply a non-mutating calculation. It could add more about limits or error behavior, but the key behavioral traits are present.

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 front-loaded purpose sentence followed by compact Args and Returns sections. Every element earns its place, and the parameter examples make the description easy to scan without being bloated.

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

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

For a four-parameter estimation tool, the description covers the core invocation details, parameter semantics, and return shape. The existence of an output schema reduces the need to describe return values further. It does not discuss authentication, rate limits, or edge cases, but those are not critical for understanding how to call this tool correctly.

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

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

The input schema has 0% description coverage, but the Args section fully compensates: it gives a concrete example for act_id, a full targeting_spec dictionary example, valid optimization_goal values, and currency examples with default behavior. This adds substantial meaning beyond the schema's bare type definitions.

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

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

The description states a clear verb and resource: 'Estimate the potential audience reach for a given targeting spec before creating an ad set.' It clearly conveys what the tool computes and when it is meant to be used. It does not explicitly contrast itself with the similar sibling get_delivery_estimate, so it narrowly misses full differentiation.

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

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

The phrase 'before creating an ad set' provides clear usage context, and the Args examples show how to construct valid inputs. However, it gives no explicit guidance about when not to use this tool or which sibling alternative (e.g., get_delivery_estimate) might be more appropriate for a different estimate.

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

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

With no annotations provided, the description carries the full burden. It discloses the return type (dictionary), pagination behavior (after/before cursors), and the default field list. It does not mention error handling or authentication, but for a read-only list operation this is adequate. The description goes beyond the schema by explaining the act_id format and field availability.

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 an Args section and a Returns line, front-loaded with the core purpose. Each sentence adds value, and the parameter documentation is organized and efficient without unnecessary 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?

The tool has an output schema, so return structure details are not required. The description covers all input parameters, defaults, pagination, and field options. For a list tool with moderate complexity, nothing essential is missing; the agent has enough to call 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, and it does thoroughly. It explains every parameter: act_id format, fields with available options and defaults, limit, and pagination cursors. This adds substantial meaning beyond the bare schema, making parameter usage clear and actionable.

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 lists saved audiences for an ad account, naming the resource (audiences) and the action (list). It is specific and distinct from sibling tools like get_custom_audiences, even without explicitly naming alternatives. No ambiguity or tautology.

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

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

The description provides no guidance on when to use this tool versus alternatives, nor does it mention any exclusions or context like 'for custom audiences use X'. The agent must infer from the name and description alone, which is not explicit enough for a multi-tool environment.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. It does describe the return shape and content: 'a dictionary containing sentence_lines — a plain-English breakdown of the targeting.' However, it does not mention authentication, error behavior, side effects, or explicitly confirm a read-only operation.

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 well-structured: a one-sentence summary followed by brief Args and Returns sections. Every line contributes useful information, and there is no filler or repetition.

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

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

For a simple one-parameter read tool, the description covers the input and the return value sufficiently, especially since an output schema exists. It lacks broader context about when to choose this tool over siblings and omits error/edge-case details, but these are relatively minor for a getter of this complexity.

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

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

The schema only declares adset_id as a required string with no description. The tool description adds a minimal semantic gloss — 'The ID of the ad set' — which compensates somewhat for the 0% schema coverage, but it provides no format, source, or usage detail beyond what the parameter name already implies.

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

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

The description states a specific verb and resource: 'Get a human-readable description of an ad set's targeting configuration.' It clearly describes what the tool does and hints at a unique output format (sentence_lines), though it does not explicitly distinguish itself from sibling tools like get_targeting_suggestions.

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

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

There is no guidance on when to use this tool versus alternatives such as get_targeting_suggestions or search_targeting_options. No context, exclusions, or selection criteria are provided, so an agent must infer appropriate usage from the name and description alone.

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

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

No annotations are provided, so the description carries the behavioral burden. It discloses the return shape ('A dictionary containing suggested targeting options') and the input/output relationship, but it doesn't mention side effects (none implied), auth requirements, or rate limits. For a read-style suggestion tool this is adequate but not rich.

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 with a one-sentence purpose, followed by a compact Args/Returns docstring. There is no filler; the example is the only extra and it earns its place.

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

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

With three parameters, a nested object, and no annotations, the description covers all required and optional inputs and states the return type. It is complete enough for an agent to invoke correctly; minor gaps like pagination or output details are covered by the output schema and are not fatal.

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 compensates by documenting all three parameters: act_id with an example, targeting_spec with a concrete JSON example, and limit with its meaning. The example for the nested targeting_spec adds real value beyond the schema's additionalProperties object.

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

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

The first sentence uses a specific verb ('Get'), names the resource ('targeting suggestions'), and anchors the operation to an existing targeting spec with an 'expand interests' example. It is clear on its own, but it doesn't explicitly differentiate from sibling tools like search_targeting_options or get_targeting_sentence_lines.

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 conveys the key usage context: call this when you already have a targeting spec and want suggestions derived from it. It doesn't state when not to use it or name alternative sibling tools, but the 'based on an existing targeting spec' condition is clear enough to guide selection.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states that the tool MUST automatically paginate through all pages, use the facebook_fetch_pagination_url tool, not stop after the first page, and return a consolidated list in a single response. This is exceptionally transparent about the tool's internal behavior and constraints.

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 appropriately structured: it leads with the core purpose, then presents a critical pagination instruction. The wording is somewhat repetitive ('CRITICAL', 'IMMEDIATELY', 'AUTOMATICALLY', 'This is a requirement') but the length is justified by the importance of the pagination behavior. It could be trimmed slightly, but it remains focused.

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 no-parameter tool with an output schema, the description fully covers the essential context. It specifies the action, the required pagination behavior, the dependency on another tool, and the expected consolidated return. There are no missing details that would prevent an agent from invoking 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 tool has zero parameters, so the schema provides no semantic information. The baseline for 0 parameters is 4, and the description adds nothing beyond confirming that there are no inputs. No parameter explanations are needed, so the score remains at baseline.

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

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

The description clearly states the verb ('List') and resource ('ad accounts and their names') associated with the Facebook account. It is specific enough to distinguish from sibling tools like get_details_of_ad_account or get_ads_by_adaccount, which target individual entities. The wording 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 guidance is given on when to use this tool versus alternatives. There is no mention of exclusions (e.g., 'use get_details_of_ad_account for a single account') or specific scenarios where this tool is preferred. The pagination instruction is behavioral, not about selection criteria.

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

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

No annotations are provided, so the description must disclose behavior fully. It does mention the required permission and the return type (a dictionary), which is helpful. However, it does not discuss pagination behavior, rate limits, or what happens when the user lacks permission (e.g., error handling). The description also states it lists 'all' pages but does not clarify if pagination is handled or not.

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, with each sentence serving a purpose: the main action, permission note, parameter explanation, and return type. It is not overly verbose. The structure is logical (purpose, permission, args, return). Minor issue: the Args section could be more compact, but overall it's 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?

The tool has a relatively simple output (a dict) and the input schema is minimal. The description covers permissions and basic parameters. However, it lacks details on pagination or error handling, which might be necessary for a complete call. Since there is an output schema, the description doesn't need to detail the return structure fully. The description is adequate but has 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 (no descriptions in the properties), but the description compensates by explaining both parameters: 'fields' lists the available field names and provides a default set, and 'limit' is described as 'Maximum number of pages to return.' This adds meaning beyond the bare schema, which only gives names and types.

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 purpose: 'List all Facebook Pages the authenticated user manages.' It identifies a specific verb ('List') and resource ('Facebook Pages'), which is clear. However, it does not explicitly contrast with sibling tools like get_page_insights or get_page_posts, but the purpose is distinct enough given the focus on managed Pages.

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 the required permission 'pages_show_list' and the scope (Pages the user manages), which provides clear context for when to use it. It does not explicitly state when not to use it or name alternatives, but the sibling list shows many other tools, so the guidance is adequate for most 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?

With no annotations, the description carries the full burden. It discloses the return type (a dictionary with IDs, names, types), which is helpful, but it does not explicitly state that the operation is read-only, mention pagination, rate limits, or error behavior. The 'search' verb makes side effects unlikely, but explicit disclosure is missing.

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 with a one-sentence summary, an Args list, and a Returns line. Each part is necessary; the only minor redundancy is the Returns section potentially duplicating the output schema, but it's still brief.

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 read/search tool with an output schema, the description covers the inputs and the output. It lacks a note on any default limit behavior or whether pagination exists, but overall it provides enough information to call the tool correctly. Given no annotations, it could be more explicit about being read-only, but that's a minor gap.

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

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

The description explains all three parameters in a dedicated Args block, providing a clear meaning for act_id (with an example), query (with examples), and limit (maximum results). Since the input schema has no descriptions, the description fully compensates and adds significant value.

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 tool searches for available targeting options by keyword, naming the resource (targeting options) and the method (by keyword). It also enumerates the categories (interests, behaviors, demographics), which distinguishes it from sibling tools like get_targeting_suggestions that likely operate on different inputs.

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 choose this tool over siblings such as get_targeting_suggestions or get_targeting_sentence_lines. There is no mention of use cases, exclusions, or prerequisites, leaving the agent to infer from the tool name.

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